Closed Bug 451299 Opened 12 years ago Closed 8 years ago
Assertion failure: JS
_CLIST _IS _EMPTY(&thread->context List), at /Code/moz/central/mozilla/js/src/jscntxt .cpp:111
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
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.) http://hg.mozilla.org/mozilla-central/index.cgi/file/73967cc9e4ee/js/src/jscntxt.cpp#l95 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? /be
No more threading stuff.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.