Closed Bug 324483 Opened 15 years ago Closed 15 years ago

Ah Crap! takes too long

Categories

(Firefox Build System :: General, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bc, Assigned: davel)

References

()

Details

(Keywords: fixed1.8.0.5, fixed1.8.1)

Attachments

(2 files, 1 obsolete file)

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.
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?
(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.
but I think this could be done in configure.in and some preprocessor foo as well.
Assignee: nobody → davel
attaching patch for bc to try on private builds
Works fine for me. You need to update the "Sleeping for 5 minutes." message though. With that it is good to go.
Blocks: 156692
updating message printed to stdout, submitting for review
Attachment #210196 - Attachment is obsolete: true
Attachment #210355 - Flags: review?
Attachment #210355 - Flags: review? → review?(dbaron)
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
Attachment #210355 - Flags: review?(dbaron) → review+
Attachment #210355 - Flags: superreview+
checked in on trunk:

/cvsroot/mozilla/xpfe/bootstrap/nsSigHandlers.cpp,v  <--  nsSigHandlers.cpp
new revision: 1.45; previous revision: 1.44                                     
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
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.
Attachment #226469 - Flags: review?
Attachment #226469 - Flags: approval1.8.1?
Attachment #226469 - Flags: approval1.8.0.5?
Attachment #226469 - Flags: review?(dbaron)
Attachment #226469 - Flags: review?(davel)
Attachment #226469 - Flags: review?
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.
Attachment #226469 - Flags: review?(davel) → review+
(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 on attachment 226469 [details] [diff] [review]
patch for 1.8 branches

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #226469 - Flags: approval1.8.0.5? → approval1.8.0.5+
Attachment #226469 - Flags: review?(dbaron) → review+
Attachment #226469 - Flags: superreview+
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
Keywords: fixed1.8.0.5
Attachment #226469 - Flags: approval1.8.1? → approval1.8.1+
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
Keywords: fixed1.8.1
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.