Closed Bug 394031 Opened 13 years ago Closed 12 years ago

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

Categories

(Toolkit :: Crash Reporting, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bzbarsky, Unassigned)

References

()

Details

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.
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.
Assignee: nobody → ted.mielczarek
OS: Linux → Mac OS X
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

Summary: Bogus stack from a crash → Bogus stack from a crash - dump_syms not handling inlined methods properly?
Assignee: ted.mielczarek → nobody
Might get fixed as a side effect of fixing bug 421534.
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Depends on: 421534
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.