Closed Bug 451299 Opened 12 years ago Closed 8 years ago

Assertion failure: JS_CLIST_IS_EMPTY(&thread->contextList), at /Code/moz/central/mozilla/js/src/jscntxt.cpp:111


(Core :: JavaScript Engine, defect)

Not set





(Reporter: sdwilsh, Unassigned)


I'm doing some fun threading stuff over in bug 450290 with JS, and I'm hitting this lovely assertion:
Assertion failure: JS_CLIST_IS_EMPTY(&thread->contextList), at /Code/moz/central/mozilla/js/src/jscntxt.cpp:111
This is with the test_database_sync_after_addBookmark.js test.

jorendorff think it has to do with XPConnect and the js engine doing their thread destruction stuff out of order.  Hopefully he can better explain what's up than I can.
Assignee: nobody → general
Component: Places → JavaScript Engine
Product: Toolkit → Core
QA Contact: places → general
Both XPConnect and SpiderMonkey use NSPR thread-private storage with destructor callbacks.

XPConnect's destructor callback destroys a context; the stack is:

  0 JS_DestroyContext
  1 XPCJSContextStack::~XPCJSContextStack
  2 XPCPerThreadData::Cleanup
  3 XPCPerThreadData::~XPCPerThreadData
  4 xpc_ThreadDataDtorCB

SpiderMonkey's destructor callback free()s the JSThread used by JS_DestroyContext.  (It also contains the assertion that's tripping here.)

So this works as long as XPConnect's destructor callback gets called first.  If SpiderMonkey's destructor callback is called first, you would get this assertion.
Er, the point of all that is, NSPR doesn't promise to call thread-private destructor callbacks in any particular order, as far as I know.  So I'm not surprised that Shawn's seeing this when playing with JS and threads in new and exciting ways.
Deja vu -- see bug 335018, read its patch that landed.

Cc'ing mrbkap. Can we keep things simple and restore order?

No longer blocks: 450290
No more threading stuff.
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.