759059 - No XUL symbols for crashes in xul.dll@0x43... from 15.0a1/20120523164348

Status: RESOLVED INCOMPLETE

(Toolkit :: Crash Reporting, defect)

Description

[Scoobidiver (away)]

There's a top crasher in the trunk with no XUL symbols from 15.0a1/20120523164348: https://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A15.0a1&range_value=4&range_unit=weeks&query_search=signature&query_type=contains&query=xul.dll%400x43&do_query=1

Guessing it's a regression, the regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=36e938e51481&tochange=d499dc65cdab

Comment 1

[(not currently active) Ted Mielczarek]

I'm not sure if this is the same crash, but khuey was looking at a crash the other day with the same symptoms. If you look at the Modules tab, you'll note that xul.dll is missing a Debug ID, which is what Breakpad uses to find the matching symbols. If you get someone to download the raw dump, you can use a Microsoft debugger + the symbol server to get a stack.

Actually, given that query you linked, it looks like that might be a bunch of different crashes, since the addresses are all different... Do we have useful reports (with symbols) on builds in this same date range? Is this just a class of similar crashes?

Comment 2

[Scoobidiver (away)]

(In reply to Ted Mielczarek [:ted] from comment #1)
> Actually, given that query you linked, it looks like that might be a bunch
> of different crashes, since the addresses are all different... 
It's the same crash because the crash address moves with each Nightly. The third frame has also two versions for each Nightly

Comment 3

[(not currently active) Ted Mielczarek]

Okay, that's a bit less scary then. I suspect this crash just causes us to crash in a way such that MinidumpWriteDump can't write out that debug identifier for some reason. I don't know why, perhaps some very specific heap corruption?

Comment 4

[Scoobidiver (away)]

Those crashes ended after 15.0a1/20120530030519.

Comment 5

[(not currently active) Ted Mielczarek]

I think this is just a subcase of OOM crashes producing empty dumps--I believe that MinidumpWriteDump memory-maps each DLL in order to get its debug ID, and xul.dll is kind of big, so when we run out of virtual memory sometimes dump writing succeeds but getting the debug ID fails. I think the fix from bug 837835 / bug 943051 should reduce the frequency of this sort of problem.