bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

ramiro's stack-trace hack should be on by default

RESOLVED FIXED in mozilla1.1beta


Core Graveyard
Cmd-line Features
19 years ago
4 years ago


(Reporter: dmose, Assigned: dbaron)



Firefox Tracking Flags

(Not tracked)



(3 attachments)



19 years ago
Casual users of the milestone builds need to be given enough information to

encourage them to easily file useful bugs.  As such, it seems to me that M10 and

 later should by default be built either with ramiro's stack trace code turned

or else mozilla-apprunner.so should default to using libSegFault.so.


19 years ago
Target Milestone: M10


19 years ago
Summary: libSegFault.so or ramiro's stack-trace hack should be default → ramiro's stack-trace hack (+ maybe libSegFault.so) should be default

Comment 1

19 years ago
Turns out that libSegFault.so as shipped with RH6 doesn't seem to give useful
stack traces for multi-threaded executables.  It does, however, dump the
registers (which might conceivably be helpful in some case).  So ramiro's hack
is definitely the one that counts.

Comment 2

19 years ago
shaver, whatcha goin' n do?  time to wrap m10.
I don't know what the effects of Ramiro's hack are on non-Linux platforms, etc.
I'm comfortable having it turned on if we think it's not a big risk for our
other Unix platforms.

Comment 4

19 years ago
So maybe the right thing to do is turn it on in the tip right now, and that will
help us shake out any problems in time to ship M11 with it on by default.

Who's going to flip the bit?
Target Milestone: M10 → M11
We're turning this on for M11, not M10.
Let's turn it on in the default build now, and see if it kicks anyone's ass.

Leaf, can you do the honours?

Comment 8

19 years ago
Sure... i take it the means of turning this on is buried somewhere in
Assignee: shaver → leaf


19 years ago


19 years ago
Target Milestone: M11 → M12

Comment 9

19 years ago
I am completely lame. I'll turn this on after M11 ships, and we can test it
before the alpha release. (now that i know where to look)


19 years ago
Target Milestone: M12 → M13

Comment 10

19 years ago
can someone post what the hack is in this bug report.
seems like we need to get a few people to try this out
at the begining of a milestone period, not at the end.
we are at the end again..  m12 shutdown starts tomorrow..
leaf's got other stuff to do durning the milestone period...

lets get a few xheads to try the patch on a few platforms
when the hack gets posted here..

Comment 11

19 years ago
the hack is broken.  some checkins broke it and its rotten now.  sorry

Comment 12

19 years ago
Any idea what it would take to fix it?


19 years ago
Target Milestone: M13 → M14

Comment 13

19 years ago
I'm a big loser. Not going to make this in m13.


19 years ago
Target Milestone: M14 → M17

Comment 14

18 years ago
Created attachment 17981 [details] [diff] [review]
Patch to make this code work again and turn it on.

Comment 15

18 years ago
Note that this code also has the useful function of causing mozilla to go to
sleep after a crash so that one can attach to it with a debugger.  This is very
handy on linux, since linux cannot dump useful cores for multithreaded apps.

Comment 16

18 years ago
testing patch.

Comment 17

18 years ago
tested on linux, seems to be working. How should i give this to reviewers@? The
patch itself that dmose has attached is tiny, but it turns on a bunch of other
It seems to work.  However, I don't know if I like the long 5 minute time out
and it just looks like a hang to a user.  Do we want it turned off for non-debug

Comment 19

18 years ago
You're right, the sleep should be turned off for non-debug builds and the
message to stderr modified to match.

Comment 20

18 years ago
leger is no longer @netscape.com
changing qa contact to default for this component
QA Contact: leger → doronr
We were discussing this on IRC today... I'll take the bug and try to get an
appropriate form of the patch in...
Assignee: leaf → dbaron
Component: Browser-General → XP Apps: Cmd-line Features
Summary: ramiro's stack-trace hack (+ maybe libSegFault.so) should be default → ramiro's stack-trace hack should be on by default
Target Milestone: M17 → mozilla0.9
Created attachment 24961 [details] [diff] [review]
patch to reenable in a way that might not break builds...
Code looks fine -- if it works, sr=brendan@mozilla.org

I'm thinking maybe this should be for DEBUG builds only.  I'm worried it:
 * might mess up talkback
 * wouldn't be too useful on builds with --enable-strip-libs

The reason I haven't checked it in yet is that it's rather intertwined with my
changes for bug 66159.

Comment 26

18 years ago
Part of my reasoning for wanting this is for people who download the nightlies
without talkback (in part because it seems like talkback goes through phases of
not working in one or the other of the installer or zip packaging).  But both of
these potential problems shouldn't be hard to test to see if they really cause
problems, I would think.
On my own non-debug build, which doesn't have --enable-strip-libs, the
stack traces are only barely useful, because the demangled symbols are
all NSGetModule, so the only way to get any useful information is through
addr2line, which will give the correct function names (but not line
numbers).  However, I suspect that with --enable-strip-libs, it won't
even be able to do that.  I guess I could try an --enable-strip-libs
build sometime...
OK, I've been running with this in my opt build for a few weeks now, and it's
caused some problems that make me not want to check it in for opt builds, and
perhaps not even at all.

In some cases I will see a crash and this code will go into an infinite loop
repeatedly printing the stack trace.  I'm not sure whether I've seen this in my
DEBUG build (where the timeout wasn't #ifdef-ed), but I know I've seen it in my
non-DEBUG build.

When this happens when I exit mozilla, I don't really notice.  However, since
I'm running my opt build from the gnome-panel rather than from an xterm window,
it spews this infinite loop to .xsession-errors, which fills up my /home
partition (yes, it fills 2.5GB of empty space) and causes my gnome/mozilla
profile data to get corrupted when programs attempt to write configurations back
to disk.  This has happened to me 3 or 4 times in the past week.

I'm not sure whether this can happen with the debugger-timeout enabled, but it's
*very* annoying, so I suggest that this shouldn't go in for optimized builds at
least until someone fixes the problem of infinite stack traces (for sure).
Since I really need to get the stuff in bug 66159 tested on Windows and Mac,
moving this to mozilla 0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Just some comments here.  I use this on a day to day basis in my opt builds.  It
would be nice to have a --enable-stacktrace or something that:

o Turned on the stack trace code
o Turned off the elf-dynstr stripper
o Added -g to CFLAGS and CXXFLAGS so symbols would work

Comment 31

17 years ago
looks like this is something that could be move off to 0.9.2..
Target Milestone: mozilla0.9.1 → mozilla0.9.2
It's part of a larger patch that I'd still like to land for 0.9.1 that involves
a bit of rearrangement of debug-only code.
Target Milestone: mozilla0.9.2 → mozilla0.9.1

Comment 33

17 years ago
I don't know if this is useful but have you looked at glibc's
undocumented backtrace* functions?
Pushing out again.  I'll try to land this early in 0.9.2.  Really.  (I should
have time this time around.)
Target Milestone: mozilla0.9.1 → mozilla0.9.2
FWIW, the backtrace* functions are nicely documented in /usr/include/execinfo.h

Comment 36

17 years ago
I guess I'm a purist but the include file documents a particular
implementation of the functions not the functions themselves, but that's
not important here.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Created attachment 46617 [details] [diff] [review]
up-to-date patch, DEBUG only (see above)
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.6
Comment on attachment 46617 [details] [diff] [review]
up-to-date patch, DEBUG only (see above)

Attachment #46617 - Flags: review+
Comment on attachment 46617 [details] [diff] [review]
up-to-date patch, DEBUG only (see above)

sr=brendan@mozilla.org -- what's not to love?

Attachment #46617 - Flags: superreview+
All fixes except for turning it on checked in.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
->0.9.8, since I haven't sent out newsgroup posts about this yet.  (Somebody
remind me in two weeks or something so I don't notice this at the very end of
every milestone. :-)
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla1.1beta
Priority: P3 → P1
Remainder of patch checked in to trunk, 2002-07-04 22:31 PDT.

Comment 44

16 years ago
Can something like this be used to fix bug 148453 on non-debug builds?
So, does anyone else think anything else should be done for this bug, or should
I close it?  (Perhaps other things to do should be filed as separate bugs?)

I'm against turning it on for opt builds based on the experiences I've had with
it filling up my .xsession-errors until my disk was full, and also since the opt
stacks aren't too useful because of the way we strip symbols out of components.

Comment 46

16 years ago
Closing this sounds fine.  Other improvements can be filed as new bugs.  Thanks
for doing this.

Comment 47

16 years ago
Yanking myself from cc.
OK, fixed then.
Last Resolved: 16 years ago
Resolution: --- → FIXED


9 years ago
Component: Cmd-line Features → Cmd-line Features
Product: Core → Core Graveyard
QA Contact: doronr → cmd-line
You need to log in before you can comment on or make changes to this bug.