http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1264138905.1264146407.1348.gz OS X 10.5 comm-1.9.1 unit test on 2010/01/21 21:41:45 { TEST-PASS | /builds/slave/comm-1.9.1-macosx-unittest/build/objdir/mozilla/_tests/xpcshell/test_mailnewsglobaldb/unit/test_index_junk_imap_online.js | test passed command timed out: 300 seconds without output, killing pid 50456 } The next test should be test_mailnewsglobaldb/unit/test_index_junk_local.js NB: Like bug 541111, I wonder if we have a too short timeout or if it's just our "broken" box again...

(In reply to comment #0) > NB: Like bug 541111, I wonder if we have a too short timeout or if it's just > our "broken" box again... And which "broken" box would that be? Hard to say if you don't even post box names...

(In reply to comment #1) > And which "broken" box would that be? Hard to say if you don't even post box > names... I meant (possible) "Parallels" misbehaviors... NB: To be explicit, I filed these 2 bugs because you asked me about these failures yesterday, but otherwise I just ignore them when we have (1) perma-orange and (2) MacOSX on Parallels.

(In reply to comment #2) > NB: To be explicit, I filed these 2 bugs because you asked me about these > failures yesterday, but otherwise I just ignore them when we have (1) > perma-orange and (2) MacOSX on Parallels. 1) We have one non-Parallels box now and from all I see it also has timeouts happening. 2) The real problems we had with Parallels were on mochitest-plain and mitigated by stepping back to 1 CPU per VM - those problems started happening on the 1-CPU configuaration and didn't change with going back to 2 CPUs and mochitest-plain seems to have no problems at all, i.e. to me, Parallels looks fixed now.

Without output from the xpcshell test, it's hard to know exactly what's going on, but the following should be noted about the test: 1) On my local box, it takes 3 seconds to run test_index_junk_local.js. 2) The test has (and all gloda tests also have) a 600 second self-destruct timer. (This is the default value for DEFAULT_LONGEST_TEST_RUN_CONCEIVABLE_SECS in mailnews/test/resources/asyncTestUtils.js). If this fires, because of how xpcshell works, we should actually get the output from the test. I'd suggest increasing your tinderbox timeout so the self-destruct has a chance to give us a better idea of what is going on. Also, I think the thunderbird tinderboxen may be the reason why we set the timeout at 10 minutes, suggesting this may not be unusual...

(In reply to comment #3) I had a look at the waterfall from now back to 2010/01/30 20:57:02 (only). > 1) We have one non-Parallels box now and from all I see it also has timeouts > happening. Unless I've missed something, *all cb-seamonkey-osx-0? builds fail after some (random) 'test_mailnewsglobaldb' test. { examples: http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1265351094.1265353626.31419.gz OS X 10.5 comm-1.9.1 unit test on 2010/02/04 22:24:54 /test_mailnewsglobaldb/unit/test_index_junk_imap_online.js | test passed + http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1265407602.1265411540.7979.gz OS X 10.5 comm-1.9.1 unit test on 2010/02/05 14:06:42 /test_mailnewsglobaldb/unit/test_gloda_content_local.js | test passed + http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1265439775.1265442340.1241.gz OS X 10.5 comm-1.9.1 unit test on 2010/02/05 23:02:55 /test_mailnewsglobaldb/unit/test_index_messages_imap_online_to_offline.js | test passed + http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1265649762.1265652923.26424.gz OS X 10.5 comm-1.9.1 unit test on 2010/02/08 09:22:42 /test_mailnewsglobaldb/unit/test_noun_mimetype.js | test passed + http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1265685420.1265688665.22272.gz OS X 10.5 comm-1.9.1 unit test on 2010/02/08 19:17:00 /test_mailnewsglobaldb/unit/test_mime_emitter.js | test passed + http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1265719694.1265722472.31231.gz OS X 10.5 comm-1.9.1 unit test on 2010/02/09 04:48:14 /test_mailnewsglobaldb/unit/test_index_messages_local.js | test passed } *only 1 cb-sea-miniosx01 build failed, and that case ('test_dm' test) is different. { http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1265153137.1265154882.31641.gz OS X 10.5 comm-1.9.1 unit test on 2010/02/02 15:25:37 /test_dm/unit/test_bug_401582.js | test passed } I'd be interested if you could point me to other (related) failures on that box. > 2) The real problems we had with Parallels were on mochitest-plain and > mitigated by stepping back to 1 CPU per VM - those problems started happening > on the 1-CPU configuaration and didn't change with going back to 2 CPUs and > mochitest-plain seems to have no problems at all, i.e. to me, Parallels looks > fixed now. Well, unless we would find a flaw in 'test_mailnewsglobaldb', Parallels (VMs) still looks broken to me. It would be interesting to check when the 2nd CPU was re-enabled and what was the situation before. (or to disable it again and monitor if it makes a difference.)

KaiRo, could you do something about it? Like to restrict the tests to the mini box (and maybe 1 VM only), ftb?

I can't limit any tests to just some random machine or collection of machines, and I won't invest any second in trying to do that. Let's hope bug 526208 will just fix all our problems.

Not fully perma-orange actually: a few runs pass. R.Fixed by bug 526208 which removed these VMs.