On Thunderbird, we've recently set up a 1.9.2 branch, and I was seeing these assertions, today I updated my 1.9.1 based build of Thunderbird and found these on bloat tests: Assertion failure: (cx)->requestDepth || (cx)->thread == (cx)->runtime->gcThread, at /builds/slave/comm-1.9.2-bloat-macosx/build/mozilla/js/src/jsapi.cpp:1194 A 1.9.2 log: http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird3.1/1261499541.1261503689.5145.gz hg bisect tells me this is a regression from bug 534051. Although this occurs on the mail bloat tests - the test has only got as far as starting up Thunderbird, indeed I can reproduce the same assertion on my own profile (just after it has finished starting up and is showing the main window). Stack: #0 JS_Assert (s=0x42706c "(cx)->requestDepth || (cx)->thread == (cx)->runtime->gcThread", file=0x427000 "/Users/moztest/comm/191/src/mozilla/js/src/jsapi.cpp", ln=1194) at /Users/moztest/comm/191/src/mozilla/js/src/jsutil.cpp:69 #1 0x00285ac3 in JS_SetGlobalObject (cx=0x1588000, obj=0x0) at /Users/moztest/comm/191/src/mozilla/js/src/jsapi.cpp:1194 #2 0x13b74628 in nsDOMWorkerRunnable::Run (this=0x1a311e40) at /Users/moztest/comm/191/src/mozilla/dom/src/threads/nsDOMThreadService.cpp:332 #3 0x0057c699 in nsThreadPool::Run (this=0x1a311990) at /Users/moztest/comm/191/src/mozilla/xpcom/threads/nsThreadPool.cpp:219 #4 0x00577bce in nsThread::ProcessNextEvent (this=0x1a312100, mayWait=1, result=0xb04cbecc) at /Users/moztest/comm/191/src/mozilla/xpcom/threads/nsThread.cpp:521 #5 0x0050073c in NS_ProcessNextEvent_P (thread=0x1a312100, mayWait=1) at nsThreadUtils.cpp:247 #6 0x00577ddd in nsThread::ThreadFunc (arg=0x1a312100) at /Users/moztest/comm/191/src/mozilla/xpcom/threads/nsThread.cpp:254 #7 0x00177213 in _pt_root (arg=0x1a312370) at /Users/moztest/comm/191/src/mozilla/nsprpub/pr/src/pthreads/ptthread.c:228 #8 0x9254d095 in _pthread_start () #9 0x9254cf52 in thread_start () Requesting blocking on both 1.9.1.x and 1.9.2 - with this assertion the bloat tests fail. Therefore we won't have any bloat figures, and we can also not be confident in the builds working correctly (note this is not an issue in 18.104.22.168).
I remember another worker fix coming onto 1.9.2, but I guess it wasn't for this? I don't think this blocks 1.9.2, but we'll want to fix it on a 1.9.2.x point release for TB for sure.
I should also clarify that comm-central plus mozilla-central builds (i.e. trunk) don't see this problem (and afaik have never seen this problem), so there may be another fix that didn't make it into branches that should have done.
The change that makes m-c and 1.9.2 happy was in the patch for bug 466254. We shouldn't take that on 1.9.1, I'll have to work up a separate patch.
Created attachment 419248 [details] [diff] [review] Patch Like so.
8 years ago
(In reply to comment #3) > The change that makes m-c and 1.9.2 happy was in the patch for bug 466254. We > shouldn't take that on 1.9.1, I'll have to work up a separate patch. I was going to complain that 1.9.2 isn't happy. However looking at our tinderboxes I've just noticed our 1.9.2 builders are building the wrong revisions :-( which also explains why I couldn't see this bug on my own 1.9.2 debug build. So without retesting, I think this is just a 1.9.1 issue.
8 years ago
Not blocking, but we'll approve a reviewed patch when you've got one
Comment on attachment 419248 [details] [diff] [review] Patch Here's the reviewed patch you requested.
Comment on attachment 419248 [details] [diff] [review] Patch Approved for 22.214.171.124, a=dveditz for release-drivers
Pushed to mozilla-1.9.1, changeset 3f77a0cc2052.