Closed Bug 540369 Opened 10 years ago Closed 10 years ago

Not getting stack traces from crashtest hangs?

Categories

(Testing :: Mochitest, defect, major)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: jgriffin)

References

Details

Attachments

(1 file)

We're supposed to get stacks for hangs in unit tests (added in bug 501034), but in this recent crashtest run, we did not.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1263783795.1263785210.1372.gz&fulltext=1
WINNT 5.2 mozilla-central debug test crashtest on 2010/01/17 19:03:15

command timed out: 1200 seconds without output
program finished with exit code 1
elapsedTime=1266.500000
TinderboxPrint: crashtest<br/><em class="testfail">T-FAIL</em>
buildbot.slave.commands.TimeoutError: command timed out: 1200 seconds without output
TinderboxPrint: crashtest<br/><em class="testfail">timeout</em>

Maybe automation.py's timeout is longer than buildbot's timeout, so buildbot killed everything first?
Severity: critical → major
runreftest.py sets the timeout to the reftest harness timeout + 30 seconds:
http://mxr.mozilla.org/mozilla-central/source/layout/tools/reftest/runreftest.py#138

The reftest harness timeout defaults to 300 seconds, so that'd be 330s.

I'm not sure what happened here, it's possible that it's a bug in the harness. Maybe debug crashtest just produces more output than the other test suites, and triggers some edge case in the harness code?
Fixed by http://hg.mozilla.org/mozilla-central/rev/9cfe5e105d1a
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee: nobody → jgriffin
whoops, the above patch fixes mochitest, but not reftest
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch patchSplinter Review
This problem was caused by comparing an object (of type ctypes.c_long()) to 0, rather than the object's value property.
Attachment #423079 - Flags: review?(ted.mielczarek)
Comment on attachment 423079 [details] [diff] [review]
patch

Ouch, good catch! I must have broken that along the way somewhere while trying to fix something else.
Attachment #423079 - Flags: review?(ted.mielczarek) → review+
Pushed as http://hg.mozilla.org/mozilla-central/rev/d08b6ddf04b6
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
It should be fixed.
I agree with that seeming non sequitur - it should be fixed, but the original push broke Windows debug builds by killing them 60 seconds into running bloatcycle, and the bustage fix attempt, http://hg.mozilla.org/mozilla-central/rev/729b45c96021, broke them by killing them at 330 seconds, and we'll see whether my carefully chosen 3540 seconds (60 seconds to spare before the buildbot timeout) in http://hg.mozilla.org/mozilla-central/rev/e436d3c5a4a6 will at least get rid of the orange, but it should be fixed with a reasonable number or a reasonable fix, not something I push while spitting blood and punching the wall.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I saw the code in the repo and it looked like you fixed it. 3.6 seems to have a good performance engine and a faster Javascript Engine. It's odd the Windows debug would be killed after 60 seconds,but it seems you have fixed it with 3540 seconds.
Debug builds are slow. It's just life.

Phil: we could probably just ditch the timeout for debug builds (passing None), since I don't know what a reasonable number would be there. If your really high number works though, that's probably fine as well.
Screw it, I set it to None:
http://hg.mozilla.org/mozilla-central/rev/72bd18630b75
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
If it's that big a problem then just set the timeout to none like Ted did or just forget about it since it's sort of a hard thing to try and fix since we don't know what's the best timeout.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.