Closed Bug 543558 Opened 15 years ago Closed 15 years ago

Assertion failure: currentCallStack && !currentCallStack->isSaved() [jscntxt.h:1340]


(Core :: JavaScript Engine, defect)

Not set





(Reporter: bent.mozilla, Assigned: luke)



(Keywords: intermittent-failure)


(2 files)

According to 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?
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,
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.
Blocks: 438871
Whiteboard: [orange]
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.
Depends on: 540627
Luke: here's your stack, since it finally happened in a debug test run
OS X 10.5.2 mozilla-central debug test mochitests-2/5 on 2010/02/04 07:23:32
s: moz2-darwin9-slave16
Attached file stack
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.
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.
Assignee: general → lw
Attachment #425341 - Flags: review?(mrbkap)
Comment on attachment 425341 [details] [diff] [review]
save frame chain from within a request

Nit: Might prefer C++-style line comments outside js/src.
Attachment #425341 - Flags: review?(mrbkap) → review+
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.