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

RESOLVED FIXED in mozilla1.9.3a1

Status

()

RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: bent.mozilla, Assigned: luke)

Tracking

({intermittent-failure})

Trunk
mozilla1.9.3a1
x86
Mac OS X
intermittent-failure
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

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?

Comment 1

9 years ago
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...
(Assignee)

Comment 2

9 years ago
I'll build and try to reproduce.
(Assignee)

Comment 3

9 years ago
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
(Assignee)

Comment 5

9 years ago
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.
Blocks: 438871
Whiteboard: [orange]
(Assignee)

Comment 7

9 years ago
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
(Assignee)

Updated

9 years ago
Duplicate of this bug: 543984
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
Created attachment 425213 [details]
stack

For posterity, since Tinderbox logs fade away.
(Assignee)

Comment 12

9 years ago
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
(Assignee)

Comment 14

9 years ago
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.
(Assignee)

Comment 15

9 years ago
Created attachment 425341 [details] [diff] [review]
save frame chain from within a request

Less racy.
Assignee: general → lw
Status: NEW → ASSIGNED
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+
http://hg.mozilla.org/mozilla-central/rev/d3189d83fddc
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Keywords: intermittent-failure
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.