Closed Bug 535071 Opened 14 years ago Closed 14 years ago

Linux crash report file ID doesn't match file ID from dumped symbols


(Toolkit :: Crash Reporting, defect)

Not set





(Reporter: dholbert, Assigned: ted)




(Keywords: regression)

My crash reports from today's nightlies haven't had useful stack information -- instead of function names, they just have module name + offset.

For example: I just triggered the crash from bug 535004, using a nightly from yesterday and a nightly from today.  Here are the results:

Yesterday's nightly (20091214030830):
* Title has signature "[@ nsSMILCSSProperty::GetBaseValue() const ]"
* Stack has symbol information (names of functions)

Today's nightly (20091215030948):
* Title has signature  "[@ ]"
* Stack has no symbol information -- just has e.g. "" at each stack level.
Pushlog for regression range:

Just got a new crash report from each build again, with the same results.

Yesterday's nightly (with symbols):
Today's nightly (no symbols):

The changes for bug 514188 ("sync to breakpad revision 437 to pick up Linux client rewrite") sounds particularly suspicious...  I guess the out-of-process-plugins patch-bomb seems suspicious too, if only because of its size.  I'm blaming bug 514188 for now, though...
Component: General → Breakpad Integration
Product: Core → Toolkit
QA Contact: general → breakpad.integration
Blocks: 514188
Keywords: regression
There's something...odd about that second crash report. We have symbols for the build with that build ID:

However, the there has the ID:

but the from your crash report has the ID:

Those don't match. So either you're running a mixed-up build, or something is broken between the symbol dumping and crashing bits.
Jim: don't suppose any of your symbol dumper changes could have caused something weird to happen here?
Ugh. The Linux client rewrite definitely broke this. Apparently the Linux File ID code changed to just calculate a hash of the first page of the file, which changes if you strip the file or anything. I guess I'll back out until I can figure out how to fix it.
I filed an upstream issue on this brokenness:
Backed out, bug 514188 reopened. Apparently bsmedberg is going to get some new nightlies spun today to fix some e10s stuff, so the new nightly today should be better.

I'll try to get this sorted out upstream so we can re-land, since the new code is otherwise much better.
Assignee: nobody → ted.mielczarek
Closed: 14 years ago
Resolution: --- → FIXED
Summary: Crash reports don't include useful stack information, starting with 20091215 nightly → Linux crash report file ID doesn't match file ID from dumped symbols
Was it expected that your backout would actually *cause* this, for Linux talos crashes? Prior to your backout, and for one of the two that tbpl claims were from your backout, the bug 528708 crashes all had the signature, then for one from the backout and all following ones, they're (assuming they really are the same thing) all just + 0xddf84 (or 0xddf44, or thereabouts).
Uh, no. The backout should have just reverted us to the previously existing Breakpad code. (I forgot to look into what happened with the debug symbols on tinderbox, I would expect things to continue working.)
You need to log in before you can comment on or make changes to this bug.