92160 - Fizzilla nightlies don't contain real function names for stack trace

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Henri Sivonen (:hsivonen)]

Build ID: 2001072005 FizzillaCFM

Steps to reproduce:
1) Enable Crash Reporter
2) Crash Fizzilla
3) Take a look at the log

or 

1) Load attachment 42968 [details].

Actual results:
The stack trace shows incomprehensible hex symbols.

Expected results:
Expected the stack trace to contain human-readable function names as was the
case when Pinkerton's earlier builds crashed.

I don't know about the performance and bloat implications that are related to
including the original function names. If they aren't too troublesome, it would
be really useful to have the real names. It seems to me that no one is
able/willing to correlate the hex symbols with real names. Hence, the crash.log
excerpts are currently quite useless.

Comment 1

[Mike Pinkerton (not reading bugmail)]

cc'ing beard and dagley. any idea why the nighlies don't have useful 
crashReporter data where my builds did? what's the difference?

Comment 2

[J.J. Enser]

*nightly* mac builds (mozilla or fizilla) are not talkback enabled. Only
*release* builds are.
According to chofmannm, there is no plan to make *any* of the fizilla builds
talkback enabled because the feedback agent is "classic" and it will not be
carbonized. I'm surprised you managed to trigger it after a crash!

Comment 3

[Mike Pinkerton (not reading bugmail)]

we're not talking about talkback. apple has a crashreporter that you can enable 
to give stack traces after an app crashes on osx. these traces are reporting 
useless hex symbols in current daily builds, where in the builds i did they would 
report the correct symbolics.

Comment 4

[J.J. Enser]

Doh. never mind.
Well, nevertheless, this bug is assigned to me and is probably related to a
build configuration issue ... let me know if there is any particular build flag
or option that needs to be turned on on the osx build mac in order to get what's
missing.

Comment 5

[Avi Drissman]

Even if you do put traceback symbols in the build, it may not help.

GDB doesn't grok CFM traceback tables terribly well, and whenever I've had my app crash I've seen 
random symbols in the traceback.

Comment 6

[Henri Sivonen (:hsivonen)]

Is there any evidence of Crash Reporter having the same problems as gdb? To me,
the stack traces from Pinkerton's old build looked quite believable.

Comment 7

[Henri Sivonen (:hsivonen)]

Attachment: Expected results--authentic log excerpt from an old crash

Comment 8

[Avi Drissman]

Then why can't they fix GDB?

Grumble... grumble...

Comment 9

[Mike Pinkerton (not reading bugmail)]

with the builds i did, crashReporter gave wonderful stack traces -- i fixed bugs 
based off them! gdb, in my experience, seems to do quite well with CFM symbol 
resolution. Yuu just can't do much other than 'bt' to find where you're stopped.

Comment 10

[J.J. Enser]

can the lack of symbols with daily builds be explained by the fact that they
come from the 0.9.2 branch, where the traceback option (in IDE_Options.h) is
turned off for optimized buids?
If so, this will be fixed as soon as we switch back to the trunk (affective in 1
or 2 days).

Comment 11

[J.J. Enser]

fyi, first trunk nightly build is available here:
ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-08-01-05-trunk/mozilla-macosX-trunk.sit.bin

please check if stack traces look better with this build or not.

Comment 12

[Henri Sivonen (:hsivonen)]

Cool. Crashes look better now. :-) However, there are still a few hex symbols
around. How are XPConnected JS calls supposed to show up? See attachment 44283 [details].

Comment 13

[Mike Pinkerton (not reading bugmail)]

i think this is as good as we're going to get

Comment 14

[Jon Granrose]

verified.