Closed Bug 424501 Opened 14 years ago Closed 14 years ago

disable gnome bug-buddy dialog from runtests

Categories

(Testing :: Mochitest, defect)

All
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ajschult784, Assigned: ajschult784)

Details

Attachments

(1 file)

Attached patch patchSplinter Review
When mochitests crash, I get the gnome bug-buddy dialog.  For an automated run, the run sits there until it times out.  runtests should disable it like run-mozilla.sh does.
Attachment #311114 - Flags: review?(jwalden+bmo)
Assignee: nobody → ajschult
Attachment #311114 - Flags: review?(jwalden+bmo) → review+
fixed
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
I backed out the runtests.pl changes because... it made firefox crash and turned tinderbox orange.  Or hang.  Or cause a test to time out.  It's hard to know really since we don't get any feedback.  Anyway, the runtests.py change is still in and I have trouble caring about the perl version.
Is there any reason the same problem wouldn't affect the tinderboxes if they switch to runtests.py ?
No.  The whole thing doesn't make sense, but my guess would be that firefox (or gtk, which is the thing that would actually look at the environment variable) has some sort of problem with the variable set.  Someone that sees the bug (mconnor said that yosh also saw a hang) needs to diagnose the problem -- the tests run fine for me.
So you're leaving the .py version checked in with a hang that will force some people to switch to the .pl version unless they know that this is the issue and know how to debug it?
It's likely nightly users are already hitting a similar problem since run-mozilla.sh sets the same environment variable.  The point of the mochitest framework is to find bugs.  We found one.  Changing the framework to avoid bugs seems like the wrong solution.

Backing out the patch for .py means that anyone that hits a crash will get the bug buddy dialog and spend their evening trying to figure out why, like I did.
Ah, I didn't realize this was something run-mozilla.sh already sets.

That said, if we want to test run-mozilla.sh, why aren't we using it?
It seems we don't use it pretty consistently for tinderbox (build-seamonkey-util.pl always invokes appname-bin directly).  The only reason I can think of off-hand would be that invoking run-mozilla.sh (or the firefox/seamonkey startup script) would make it more complicated to kill a runaway process.
Component: Testing → Mochitest
Product: Core → Testing
QA Contact: testing → mochitest
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.