http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1287594999.1287596951.19764.gz Rev3 MacOSX Leopard 10.5.8 mozilla-central debug test xpcshell on 2010/10/20 10:16:39 s: talos-r3-leopard-007 TEST-UNEXPECTED-FAIL | /Users/cltbld/talos-slave/mozilla-central_leopard-o-debug_test-xpcshell/build/xpcshell/tests/services/sync/tests/unit/test_syncengine_sync.js | test failed (with xpcshell return code: 1), see following log: ... Assertion failure: *(uint64*)&tm->storage->global()[globalSlots] == 0xdeadbeefdeadbeefLL, at /builds/moz2_slave/mozilla-central-macosx-debug/build/js/src/jstracer.cpp:6752 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1287578008.1287581310.6826.gz Rev3 MacOSX Snow Leopard 10.6.2 mozilla-central debug test xpcshell on 2010/10/20 05:33:28 s: talos-r3-snow-023 Assertion failure: *(uint64*)&tm->storage->global()[globalSlots] == 0xdeadbeefdeadbeefLL, at /builds/slave/mozilla-central-macosx64-debug/build/js/src/jstracer.cpp:6711
This is a pretty bad bug. It means the tracer wrote beyond the allocated stack area.
blocking2.0: --- → ?
Do we know when this started? A regression range would be great.
Maybe in something that came over to mozilla-central in the http://hg.mozilla.org/mozilla-central/rev/eae6bdacf6d2 merge Monday - I went back through last Friday, and the only other one I found was http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1287544471.1287547562.8731.gz Rev3 MacOSX Snow Leopard 10.6.2 mozilla-central debug test xpcshell on 2010/10/19 20:14:31
And I looked back through October 8th on TM, without finding any instances at all of it there.
Also worth noting that this is one of several tests that have been timing out like mad, also Mac-only, in bug 604565, which is about to disable them.
This hasn't happened since the 10th of last month. I suspect this was fixed by the changes we took to prevent XPCWrappedJS objects from being passed from one thread to another. If this reappears, please reopen.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Note comment 5 - we stopped running the test that was triggering it on the only OS where we ever saw it, so while I'm completely willing to believe you, we have absolutely no evidence either way.
Coincidentally, two hours ago I started running test_syncengine_sync.js in a loop on debug OS X 10.5 with no assertion. Since (mrbkap tells me) each xpcshell test gets its own process instance, this shouldn't be an "only crashes when run in a batch with other tests" situation, so there is evidence that the test was actually fixed.
Whiteboard: [sg:critical][orange] → [sg:critical]
You need to log in before you can comment on or make changes to this bug.