Closed Bug 493108 Opened 15 years ago Closed 12 years ago

Signature ranked #8 in Fx3.0.10 Mac query is blank

Categories

(Socorro :: General, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: alqahira, Assigned: ted)

References

()

Details

I just ran a basic query on crash-stats: Firefox 3.0.10 Mac OS X, and on the query results page (URL field), the signature ranked #8 (with 1486 crashes in the last week) is blank.

HTML looks like:

                                <tr class="odd">
                <td>8</td>
                <td>
                    <a href="/report/list?product=Firefox&amp;version=Firefox%3A3.0.10&amp;platform=mac&amp;query_search=signature&amp;query_type=exact&amp;query=&amp;date=&amp;range_value=1&amp;range_unit=weeks&amp;do_query=1&amp;signature=" title="View reports with this signature."></a>
                </td>
                <th>1486</th>                                    <td>0</td>

                                    <td>1486</td>
                                    <td>0</td>
                                    <td>0</td>
                            </tr>
Lars, any idea why this happened?
By the time this bug came to my attention, the Socorro database had gone down for a hardware upgrade.  Both the production server and my development database are down until sometime during the night.  I cannot investigate until 2009/05/16.
However, I can speculate.  A couple days ago, I was running some queries for Chofmann and we encountered some blank signatures.  The field "processor_notes" on individual crashes stated that the processor was unable able to make a signature because no frame information was returned by minidump_stackwalk.  In each case, minidump_stackwalk had failed to process the crash dump and returned a non-zero error code.  I will conjecture that when I do get the chance to investigate this specific instance of signature-less crashes, I will find the same story.
I've got my database back so I can proceed. 

As I expected, all crashes with empty signatures have corresponding complaints from the processor about minidump_stackwalk not providing information about which thread crashed.  However, in 1411 crashes between Monday and Thursday of this week, the processor made the aforementioned complaint but did not go on to say that minidump_stackwalk failed with an error code.  Interestingly, the Socorro UI is not able to show me the processed dump for any of these 1411 crashes. 

I have made a request to aravind to fetch for me any information that he can about these crashes from the filesystem storage.  I must wait until he responds before I can continue my investigation.
Ok, I've got a hold of some most unusual crash dumps.  The 1411 crashes are all from MacOS/X, so this appears to be the same one you're talking about.  minidump_stackwalk is claiming that they aren't actual crashes at all: there's no module list and no symbols, only bare addresses in the stack frames.  Note the third line in the example below.  Processor's complaint, "No thread was identified as the cause of the crash; No signature could be created because we do not know which thread crashed" seems legitimate.

OS|Mac OS X|10.5.6 9G55
CPU|x86|GenuineIntel family 6 model 15 stepping 6|2
Crash|No crash||
0|0|||||0x1c05be31
0|1|||||0x1c05ef81
0|2|||||0x1c06115d
0|3|||||0x1c1bcdfc
0|4|||||0x1c1bdd77
0|5|||||0x1c37307b
0|6|||||0x1c2d392f
...
So the Breakpad client/"crash handler" is failing to write a valid dump when the crash happens?  (We just had one of these show up in the Camino 2.0b3 crashes, http://tinyurl.com/ljlkte #15, which caused me to remember this bug.)
It looks like a valid dump, the processor isn't crashing on it, it's just not producing any useful data. In this case, it looks like the minidump is just missing an Exception object, which indicates the cause of the crash and the crashing thread. This can happen when we manually request a dump, like we do on Windows for CRT invalid parameter handling / pure virtual function call handling.

http://code.google.com/p/google-breakpad/source/browse/trunk/src/client/mac/handler/exception_handler.cc#317

It does look like we can get into this state if the exception handler itself creates an exception:
http://code.google.com/p/google-breakpad/source/browse/trunk/src/client/mac/handler/exception_handler.cc#479
A similar problem exists currently with the #5 top crash on Mac for Firefox 3.5 which shows 711 crashes.
Dup of bug 397199?

The non-clickable link is pretty wacky.  I wouldn't mind that being fixed even before we can get better reasons / stacks for these crashes.
Depends on: 397199
Interestingly, there are some Windows crashes in that list.
We need to figure out why a blank signature is coming from the breakpad code.
Assignee: nobody → ted.mielczarek
These look like partially malformed minidumps, in that they're missing lots of information that we need to do anything useful, like a module list and an exception object. It's hard to do anything about them unless we can find a reproducible testcase for one of these crashes.
Component: Socorro → General
Product: Webtools → Socorro
File a new bug if you see this again
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.