Intermittent Assertion failure: *(uint64*)&tm->storage->global()[globalSlots] == 0xdeadbeefdeadbeefLL in test_syncengine_sync.js

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
9 years ago
4 years ago

People

(Reporter: philor, Unassigned)

Tracking

({intermittent-failure, regression})

Trunk
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+, status1.9.2 unaffected, status1.9.1 unaffected)

Details

(Whiteboard: [sg:critical])

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.
Group: core-security
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.
Whiteboard: [orange] → [sg:critical][orange]
blocking2.0: ? → betaN+
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.
Group: core-security
Whiteboard: [sg:critical][orange] → [sg:critical]
You need to log in before you can comment on or make changes to this bug.