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)
Socorro
General
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&version=Firefox%3A3.0.10&platform=mac&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&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>
Comment 1•15 years ago
|
||
Lars, any idea why this happened?
Comment 2•15 years ago
|
||
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.
Comment 3•15 years ago
|
||
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.
Comment 4•15 years ago
|
||
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.
Comment 5•15 years ago
|
||
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 ...
Reporter | ||
Comment 6•15 years ago
|
||
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.)
Assignee | ||
Comment 7•15 years ago
|
||
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
Comment 9•15 years ago
|
||
A similar problem exists currently with the #5 top crash on Mac for Firefox 3.5 which shows 711 crashes.
Comment 10•15 years ago
|
||
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
Comment 11•15 years ago
|
||
http://bit.ly/crashinnull
Assignee | ||
Comment 12•15 years ago
|
||
Interestingly, there are some Windows crashes in that list.
Comment 13•15 years ago
|
||
We need to figure out why a blank signature is coming from the breakpad code.
Assignee: nobody → ted.mielczarek
Assignee | ||
Comment 14•15 years ago
|
||
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.
Updated•13 years ago
|
Component: Socorro → General
Product: Webtools → Socorro
Comment 15•12 years ago
|
||
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.
Description
•