Last Comment Bug 324483 - Ah Crap! takes too long
: Ah Crap! takes too long
Status: RESOLVED FIXED
: fixed1.8.0.5, fixed1.8.1
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: ---
Assigned To: Dave Liebreich [:davel]
:
Mentors:
http://lxr.mozilla.org/mozilla/search...
Depends on:
Blocks: 156692
  Show dependency treegraph
 
Reported: 2006-01-23 21:29 PST by Bob Clary [:bc:]
Modified: 2006-11-10 12:14 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
make gdb sleep interval configurable via env var (2.37 KB, patch)
2006-01-30 17:30 PST, Dave Liebreich [:davel]
no flags Details | Diff | Splinter Review
previous patch + change message to report actual sleep time (2.71 KB, patch)
2006-02-01 08:13 PST, Dave Liebreich [:davel]
dbaron: review+
dbaron: superreview+
Details | Diff | Splinter Review
patch for 1.8 branches (3.06 KB, patch)
2006-06-20 23:58 PDT, Bob Clary [:bc:]
dbaron: review+
mozmail: review+
dbaron: superreview+
dveditz: approval1.8.0.5+
mtschrep: approval1.8.1+
Details | Diff | Splinter Review

Description Bob Clary [:bc:] 2006-01-23 21:29:32 PST
ah_crap_handler sleep time should be configurable by environment variable

In *nix debug builds, the default signal handler does a sleep(300) after a crash to enable the developer time to attach a debugger. The 300 seconds is hard coded and not configurable.

This causes problems in automated testing of debug builds by preventing a crash from returning in a reasonable amount of time. This results in misidentifying crashes as hangs as well as increases the time required to cycle through crash tests.
Comment 1 Dave Liebreich [:davel] 2006-01-23 22:18:54 PST
Bob,

I'm not sure if PR_GetEnv() and atoi() are safe to call from inside a signal handler.  If they are, then this is a trivial change.

If not, then would a workable alternative be a flag or env var to suppress the signal handler entirely?
Comment 2 Bob Clary [:bc:] 2006-01-23 22:38:12 PST
(In reply to comment #1)

> If not, then would a workable alternative be a flag or env var to suppress the
> signal handler entirely?

That would work for me.
Comment 3 Bob Clary [:bc:] 2006-01-23 22:42:34 PST
but I think this could be done in configure.in and some preprocessor foo as well.
Comment 4 Dave Liebreich [:davel] 2006-01-30 17:30:22 PST
Created attachment 210196 [details] [diff] [review]
make gdb sleep interval configurable via env var

attaching patch for bc to try on private builds
Comment 5 Bob Clary [:bc:] 2006-01-31 01:49:28 PST
Works fine for me. You need to update the "Sleeping for 5 minutes." message though. With that it is good to go.
Comment 6 Dave Liebreich [:davel] 2006-02-01 08:13:48 PST
Created attachment 210355 [details] [diff] [review]
previous patch + change message to report actual sleep time

updating message printed to stdout, submitting for review
Comment 7 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-02-07 15:30:37 PST
Comment on attachment 210355 [details] [diff] [review]
previous patch + change message to report actual sleep time

I'm not crazy about the name MOZ_GDB_SLEEP, but I can't think of anything better offhand.  r=dbaron
Comment 8 Dave Liebreich [:davel] 2006-02-08 13:39:20 PST
checked in on trunk:

/cvsroot/mozilla/xpfe/bootstrap/nsSigHandlers.cpp,v  <--  nsSigHandlers.cpp
new revision: 1.45; previous revision: 1.44                                     
Comment 9 Bob Clary [:bc:] 2006-06-20 23:58:01 PDT
Created attachment 226469 [details] [diff] [review]
patch for 1.8 branches

I know it is late for the 1.8.x trains, but this should be very low risk and would make my life easier on the branches. This has baked on the trunk for 4 months.
Comment 10 Dave Liebreich [:davel] 2006-06-21 10:40:48 PDT
Comment on attachment 226469 [details] [diff] [review]
patch for 1.8 branches

looks to be identical to the trunk patch, so I think it will be ok.  I suggest you get additional review, just to be sure.
Comment 11 Bob Clary [:bc:] 2006-06-21 10:44:37 PDT
(In reply to comment #10)

Yeah, the original patch didn't apply due to bit rot. This patch is just a hand coded version of yours that would apply to the 1.8.x trees.
Comment 12 Daniel Veditz [:dveditz] 2006-06-21 14:40:26 PDT
Comment on attachment 226469 [details] [diff] [review]
patch for 1.8 branches

approved for 1.8.0 branch, a=dveditz for drivers
Comment 13 Bob Clary [:bc:] 2006-06-21 21:19:24 PDT
checked in on MOZILLA_1_8_0_BRANCH

Checking in nsSigHandlers.cpp;
/cvsroot/mozilla/xpfe/bootstrap/nsSigHandlers.cpp,v  <--  nsSigHandlers.cpp
new revision: 1.41.26.1; previous revision: 1.41
done
Comment 14 Bob Clary [:bc:] 2006-06-22 15:32:22 PDT
checked in on MOZILLA_1_8_BRANCH

Checking in nsSigHandlers.cpp;
/cvsroot/mozilla/xpfe/bootstrap/nsSigHandlers.cpp,v  <--  nsSigHandlers.cpp
new revision: 1.41.18.1; previous revision: 1.41
done

Note You need to log in before you can comment on or make changes to this bug.