399645 - Don't get useful crash stats anymore

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Bruno 'Aqualon' Escherl]

Attachment: dump from crash-reporter

I tested the testcase from bug 399013. All four tests resulted in crash reports without any infos.

Those are the Crash IDs:

bp-0fa81e59-790f-11dc-83dd-001a4bd43ed6
bp-1a58c991-790f-11dc-9423-001a4bd43e5c
bp-2458b9cc-790f-11dc-8e3f-001a4bd43ef6
bp-3dd82175-790f-11dc-9bd6-001a4bd43ed6

All tests were made with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101204 Minefield/3.0a9pre, but I also don't get anything useful from latest SeaMonkey nightlies.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101310 Minefield/3.0a9pre

I see something similar I think nearly as long as Breakpad exists:
bp-c8c3087a-79b7-11dc-be5b-001a4bd43e5c

Comment 2

[(not currently active) Ted Mielczarek]

So here's the culprit:
2007-10-17 21:22:23: minidump.cc:2094: ERROR: MinidumpModuleList could not read module auxiliary data for module 36/62

At least one of the modules in the module list is screwy, and the processor gives up processing the module list if that happens, so you don't get any modules, so you get a crap stack.  I'm going to file this over at the Breakpad site.  FWIW, you still wouldn't get a good stack with those builds anyway, since they're hourly builds.

Comment 3

[(not currently active) Ted Mielczarek]

Filed http://code.google.com/p/google-breakpad/issues/detail?id=222, btw

Comment 4

[(not currently active) Ted Mielczarek]

Also, the module it's dying on is C:\WINDOWS\system32\Syncor11.dll, which Google says is an audio driver, fwiw.

Comment 5

[(not currently active) Ted Mielczarek]

Ok, we've updated the processor on the staging server.  Can you try submitting a crash report there so we can see if it will work properly?  If so, we can get production updated.

In your environment, set MOZ_CRASHREPORTER_URL=http://crash-reports.stage.mozilla.com/submit then submit a crash report.  You'll be able to look it up at http://crash-reports.stage.mozilla.com/reports/

Thanks!

Comment 6

[Bruno 'Aqualon' Escherl]

I needed some time to get it to work, but finally there was a crash report with correct symbols: http://crash-reports.stage.mozilla.com/reports/report/index/69e1414a-8649-11dc-af36-001321b0783d

The same testcase from bug 368183 shows the old problem on production: 272e667a-864a-11dc-b1dc-001a4bd43ed6

In both cases I used Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070701 Minefield/3.0a6pre.

Comment 7

[(not currently active) Ted Mielczarek]

Ok, I'll leave this open until we get that fix rolled out to production in bug 400437.  Thanks for verifying.

Comment 8

[Michael Morgan [:morgamic]]

Should be fixed, could someone reopen if there are still issues?

Comment 9

[Ria Klaassen (not reading all bugmail)]

I still get very dull breakpad reports:
http://crash-stats.mozilla.com/report/index/f703800a-d7fe-11dc-8cbd-001a4bd43ed6

Comment 10

[(not currently active) Ted Mielczarek]

That looks like you're using an hourly, not a nightly. We have a bug on getting symbols uploaded for hourlies, but it's not a big priority.

Comment 11

[Ria Klaassen (not reading all bugmail)]

Crash reason: no crash. (Bug 419326)
http://crash-stats.mozilla.com/report/index/5596a559-e334-11dc-81a7-001a4bd43e5c

Comment 12

[(not currently active) Ted Mielczarek]

Not related.  Looks like you hit an invalid parameter handler or something.  We had a bug on that, but it's definitely filed upstream:
http://code.google.com/p/google-breakpad/issues/detail?id=170