540369 - Not getting stack traces from crashtest hangs?

Status: RESOLVED FIXED

(Testing :: Mochitest, defect)

Description

[Jesse Ruderman]

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?

Comment 1

[(not currently active) Ted Mielczarek]

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?

Comment 2

[Jonathan Griffin (:jgriffin)]

Fixed by http://hg.mozilla.org/mozilla-central/rev/9cfe5e105d1a

Comment 3

[Jonathan Griffin (:jgriffin)]

whoops, the above patch fixes mochitest, but not reftest

Comment 4

[Jonathan Griffin (:jgriffin)]

Attachment: patch

This problem was caused by comparing an object (of type ctypes.c_long()) to 0, rather than the object's value property.

Comment 5

[(not currently active) 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.

Comment 6

[Jonathan Griffin (:jgriffin)]

Pushed as http://hg.mozilla.org/mozilla-central/rev/d08b6ddf04b6

Comment 7

[Eric Dorman]

It should be fixed.

Comment 8

[Phil Ringnalda (:philor)]

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.

Comment 9

[Eric Dorman]

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.

Comment 10

[(not currently active) Ted Mielczarek]

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.

Comment 11

[(not currently active) Ted Mielczarek]

Screw it, I set it to None:
http://hg.mozilla.org/mozilla-central/rev/72bd18630b75

Comment 12

[Eric Dorman]

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.