394031 - Bogus stack from a crash - dump_syms not handling inlined methods properly?

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Boris Zbarsky [:bzbarsky]]

The stack at http://crash-stats.mozilla.com/report/index/69878b4f-5429-11dc-a107-001a4bd46e84?date=2007-08-26-23 seems to be somewhat bogus.  In particular:

1)  The line numbers in frames 0 and 3 are clearly wrong (bigger than the number of lines in the file).  Those functions _are_ in that file, so this doesn't loo like http://code.google.com/p/google-breakpad/issues/detail?id=188

2)  The callstack between frame 10 and frame 11 is wrong. nsCounterManager::AddResetOrIncrement doesn't call nsTextFrame::PaintText directly.

Comment 1

[(not currently active) Ted Mielczarek]

The line numbers printed by dump_syms seem to be all over the place:
FUNC 7d9e32 87 0 GetWordFontOrGroup(gfxTextRun*, unsigned int, unsigned int)
7d9e32 10 175 1545
7d9e42 8 66 1545
7d9e4a 6 1085 1545
7d9e50 12 179 1545
7d9e62 3 814 1545
7d9e65 12 181 1545
7d9e77 e 182 1545
7d9e85 2 183 1545
7d9e87 7 190 1545
7d9e8e 12 186 1545
7d9ea0 6 187 1545
7d9ea6 7 188 1545
7d9ead 7 190 1545
7d9eb4 6 575 1545

The fields in those rows are offset, size, line number, source file ID.  I'm going to debug this further.

The second issue is a bit tough to debug, unless we could get our hands on the actual minidump file.

Comment 2

[(not currently active) Ted Mielczarek]

FWIW, #1 is probably the same as bug 406998, which dealt with not handling inlined functions properly.  It was fixed for Linux upstream in http://code.google.com/p/google-breakpad/issues/detail?id=235, I've filed an upstream issue for OSX as well: http://code.google.com/p/google-breakpad/issues/detail?id=237

Comment 3

[(not currently active) Ted Mielczarek]

Might get fixed as a side effect of fixing bug 421534.

Comment 4

[(not currently active) Ted Mielczarek]

Yeah, this looks ok in the latest symbol dumps using DWARF. Here's the comparable bit of the symbol output, where I've added the file names that correspond to the file numbers in the output:

FUNC a3ffc0 a4 0 GetWordFontOrGroup
a3ffc0 e 289 16059     hg:hg.mozilla.org/mozilla-central:gfx/thebes/src/gfxTextRunWordCache.cpp:a1c1a8bfd19e
a3ffce 6 289 16059
a3ffd4 3 1097 16134   ../../../dist/include/thebes/gfxFont.h
a3ffd7 8 292 16059     hg:hg.mozilla.org/mozilla-central:gfx/thebes/src/gfxTextRunWordCache.cpp:a1c1a8bfd19e
a3ffdf 3 293 16059
a3ffe2 4 292 16059
a3ffe6 b 307 16059
a3fff1 3 66 16129       ../../../dist/include/xpcom/nsTArray.h
a3fff4 3 297 16059     hg:hg.mozilla.org/mozilla-central:gfx/thebes/src/gfxTextRunWordCache.cpp:a1c1a8bfd19e
a3fff7 2 66 16129       ../../../dist/include/xpcom/nsTArray.h
a3fff9 3 1384 16134   ../../../dist/include/thebes/gfxFont.h
a3fffc 4 297 16059     hg:hg.mozilla.org/mozilla-central:gfx/thebes/src/gfxTextRunWordCache.cpp:a1c1a8bfd19e
a40000 3 1384 16134 ../../../dist/include/xpcom/nsTArray.h

You can see that it's correctly handling inlined methods there.