Diagnosing Ts Failures

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Diagnosing Ts Failures

Dietrich Ayala-2
After applying the patch in bug 328159, Ts tests were failing, so the patch was backed out. However,
I'm running a local Tinderbox, and the tests are running fine there. The log entries from the failed
tests [1,2] look like this:

StartupPerformanceTest: test failed
cmd = sync; sleep 5
StartupPerformanceTest: test failed
cmd = sync; sleep 5
StartupPerformanceTest: test failed
cmd = sync; sleep 5

etc, etc, which doesn't really say anything. Is this output typical for a "startup took too damn
long" test failure?

I traced it back to the print_test_errors() function in build-seamonkey-util.pl, which doesn't seem
to output anything in the test results above.

thanks,

-d

1. http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1146373440.7180.gz&fulltext=1
2. http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1146373800.17394.gz&fulltext=1
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: Diagnosing Ts Failures

Vladimir Vukicevic-3
(Not sure if you already got an answer to this somewhere, but...)

> After applying the patch in bug 328159, Ts tests were failing, so the
> patch was backed out. However, I'm running a local Tinderbox, and the
> tests are running fine there. The log entries from the failed tests
> [1,2] look like this:
>
> StartupPerformanceTest: test failed
> cmd = sync; sleep 5
> StartupPerformanceTest: test failed
> cmd = sync; sleep 5
> StartupPerformanceTest: test failed
> cmd = sync; sleep 5
> etc, etc, which doesn't really say anything. Is this output typical
> for a "startup took too damn long" test failure?

Unfortunately, it could mean a bunch of different things.  In some cases,
test failed also means test succeeded, as long as some magic string was printed
beforehand.  The tinderbox tests do a /really/ bad job of tracking exit and
exit conditions -- some of them exit by themselves (except on Mac, where
this is rocket science, because Firefox can be open without any windows).
 So, your Ts failure there could either be that it timed out entirely, or
that it never got the "I'm up" string cookie, or that something crashed during
startup, etc.  Watching what happens on the tinderbox's display is often
helpful (though it does skew the results, especially if RDP is involved under
windows -- if noone's connected, any rendering operations become mostly noop's).

    - Vlad


_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds