According to http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1265058818.1265059392.21238.gz&fulltext=1 the DOM Worker test "test_closeOnGC.html" is somehow triggering this JS assertion. Assigning to JSEng for the moment until we can figure out where the problem actually is. I've never seen this before, so maybe it's an extremely unlikely random?

No, this is JS engine (see blocking bug). Stack would be extremely helpful here, if someone can get it quickly -- I'm a little preoccupied with other things for the moment...

I'll build and try to reproduce.

I did 'make mochitest-plain' on an m-c tip Debug Mac build without error. If I read the tinderbox error log above correctly, the assertion happened between test_closeOnGC.html and the next test, so I ran: 'TEST_PATH=dom/src/threads make mochitest-plain' several times, also without error. Is there any way to get core dumps out of tinderbox for this assertion?

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1265104646.1265105882.16698.gz OS X 10.5.2 mozilla-central debug test mochitests-2/5 on 2010/02/02 01:57:26 s: moz2-darwin9-slave19

I am having difficulty reproducing this assertion. I have started running the offending mochitest chunk (--total-chunks=5 --this-chunk=2 --chunk-by-dir=4) in a loop so I can collect the core file (which, for this assertion, should illuminate the cause). I really wish tinderbox would collect all core files produced during a run and serve them along with the builds.

Even though I believe in coincidence, it seems a stretch to believe that today's assertion in the same test, http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1265151280.1265152271.32098.gz&fulltext=1#err0 OS X 10.5.2 mozilla-central debug test mochitests-2/5 on 2010/02/02 14:54:40 s: moz2-darwin9-slave09 Assertion failure: suspendedFrame, at /builds/slave/mozilla-central-macosx-debug/build/js/src/jscntxt.h:258 is a separate bug.

I think you're right. I've run the offending mochitest chunk probably 20 times, without crash. bug 540627 should provide a minidump, and Ted was talking about hacking it up tomorrow.

Luke: here's your stack, since it finally happened in a debug test run http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1265297012.1265297786.22226.gz&fulltext=1#err0 OS X 10.5.2 mozilla-central debug test mochitests-2/5 on 2010/02/04 07:23:32 s: moz2-darwin9-slave16

For posterity, since Tinderbox logs fade away.

The callstack shows the main thread executing JS and then going into cycle collection while a second thread is also running JS (paused for GC of course) while processing an XHR request. Unfortunately, this is not as simple as I'd hoped. Based on the concurrency aspect, I can see why its difficult to reproduce on the 8-core Mac I've been using. John is helping me get a Tinderbox machine so I can reproduce and debug.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1265319123.1265320092.21954.gz&fulltext=1 OS X 10.5.2 mozilla-central debug test mochitests-2/5 on 2010/02/04 13:32:03 s: moz2-darwin9-slave02

So, I think Blake nailed the problem as a pre-existing bug where JS_{Save,Restore}FrameChain get called outside a request. Adding a CHECK_REQUEST assert in these functions showed that indeed this was happening. Also, the failing assertion (in the above callstack) happens right after the same assertion just succeeded -- definite race-condition material. The varobj-removal patch just exposed the problem by doing more computation in these functions (thereby increasing probability of collision) and asserting more stuff. Patch soon.

Less racy.

Comment on attachment 425341 [details] [diff] [review] save frame chain from within a request Nit: Might prefer C++-style line comments outside js/src.