Please report any other irregularities here.
In bughunter we see more and more : Assertion failure: isEmpty() (failing this assertion means this LinkedList's creator is buggy: it should have removed all this list's elements before the list's destruction), at c:\builds\moz2_slave\m-cen-w32-d-000000000000000000\build\src\obj-firefox\dist\include\mozilla/LinkedList.h:332 the problem on this is that this is making crash detection more complicated and we might miss regressions because of this Waldo, froydnj , seems you were working on this, can you take a look ? thanks!
(In reply to Carsten Book [:Tomcat] from comment #0) > In bughunter we see more and more : > Assertion failure: isEmpty() (failing this assertion means this LinkedList's > creator is buggy: it should have removed all this list's elements before the > list's destruction), at > c:\builds\moz2_slave\m-cen-w32-d-000000000000000000\build\src\obj- > firefox\dist\include\mozilla/LinkedList.h:332 > > the problem on this is that this is making crash detection more complicated > and we might miss regressions because of this > > Waldo, froydnj , seems you were working on this, can you take a look ? > thanks! Do we not have stacks to tell us what LinkedList is not getting cleared? That's the important piece of information here, and should be reflected in the call stack.
bc, do you have a stack? the log i saw didn't generated one, but you might have more insight to get a stack
The stacks are available from the crash reports. There are a variety of different stacks with this assertion so there may be more than one bug involved here.
This assertion indicates a problem with the caller, not with mfbt code. mfbt has nothing to do with anything that hits this assertion -- it's all on the callers. When filing bugs for this stuff, you should set needinfo corresponding to the location of the stack frame that *triggered* this assertion. Not against mfbt, or against froydnj or me. :-)
Created attachment 8744079 [details] stack steps to reproduce are to start the browser from the command line with -silent, e.g. firefox-debug/dist/bin/firefox -silent -profile /tmp/foobar
I'm seeing this locally on OS X a lot, I get this assertion failure during shutdown. Stack looks similar to the one Bob posted in comment 5, it looks like a JS compartment is holding the linked list? Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 XUL 0x000000010e34dd42 mozilla::LinkedList<js::UnboxedLayout>::~LinkedList() + 178 (LinkedList.h:329) 1 XUL 0x000000010e3200e0 JSCompartment::~JSCompartment() + 944 (ArrayBufferObject.h:497) 2 XUL 0x000000010e368587 JS::Zone::sweepCompartments(js::FreeOp*, bool, bool) + 583 (Utility.h:249) 3 XUL 0x000000010e3688bd js::gc::GCRuntime::sweepZones(js::FreeOp*, bool) + 381 (jsgc.cpp:3898) 4 XUL 0x000000010e375987 js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason) + 1623 (jsgc.cpp:6258) 5 XUL 0x000000010e3765bc js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason) + 460 (jsgc.cpp:6448) 6 XUL 0x000000010e376f35 js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason) + 741 (jsgc.cpp:6553) 7 XUL 0x000000010e366456 js::gc::GCRuntime::gc(JSGCInvocationKind, JS::gcreason::Reason) + 86 (jsgc.cpp:6614) 8 XUL 0x000000010e5da23c JSRuntime::~JSRuntime() + 844 (Runtime.cpp:426) 9 XUL 0x000000010e2a2746 JS_DestroyRuntime(JSRuntime*) + 22 (Utility.h:249) 10 XUL 0x0000000109c7bb52 mozilla::CycleCollectedJSRuntime::~CycleCollectedJSRuntime() + 226 (CycleCollectedJSRuntime.cpp:475) 11 XUL 0x000000010a69e8be XPCJSRuntime::~XPCJSRuntime() + 14 (mozalloc.h:210) 12 XUL 0x000000010a6e8b0a nsXPConnect::~nsXPConnect() + 138 (nsXPConnect.cpp:107) 13 XUL 0x000000010a6e8b4e nsXPConnect::~nsXPConnect() + 14 (mozalloc.h:210) 14 XUL 0x000000010a6e89b1 nsXPConnect::Release() + 97 (nsXPConnect.cpp:42) 15 XUL 0x000000010a6acc49 xpcModuleDtor() + 9 (XPCJSID.cpp:267) 16 XUL 0x0000000109d0798c nsTArray_Impl<nsAutoPtr<nsComponentManagerImpl::KnownModule>, nsTArrayInfallibleAllocator>::RemoveElementsAt(unsigned long, unsigned long) + 124 (nsCOMPtr.h:403) 17 XUL 0x0000000109d02cc0 nsComponentManagerImpl::Shutdown() + 192 (nsComponentManager.cpp:912) 18 XUL 0x0000000109d40b75 mozilla::ShutdownXPCOM(nsIServiceManager*) + 1477 (XPCOMInit.cpp:991) 19 XUL 0x000000010d55e90a ScopedXPCOMStartup::~ScopedXPCOMStartup() + 186 (nsAppRunner.cpp:1473) 20 XUL 0x000000010d5661b7 XREMain::XRE_main(int, char**, nsXREAppData const*) + 1175 (mozalloc.h:210) 21 XUL 0x000000010d56645e XRE_main + 238 (nsAppRunner.cpp:4559) 22 org.mozilla.nightlydebug 0x0000000109219114 main + 2212 (nsBrowserApp.cpp:220) 23 org.mozilla.nightlydebug 0x0000000109218534 start + 52
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
Version: unspecified → 49 Branch
An easy fix for this would be to add: unboxedLayouts.clear(); wasmModuleWeakList.clear(); to the JSCompartment dtor. However, it's unclear to me whether that would just be hiding a bug elsewhere that should be fixed.
(In reply to Jonathan Watt [:jwatt] from comment #7) > An easy fix for this would be to add: > > unboxedLayouts.clear(); > wasmModuleWeakList.clear(); > > to the JSCompartment dtor. However, it's unclear to me whether that would > just be hiding a bug elsewhere that should be fixed. That would be hiding a bug elsewhere, and would probably just move the assertion later as the heap would stilll not be empty. I just checked in bug 1268992, which should print the leaking edges before we get to this crash. That should allow us to use the CC leak logs to quickly track down the bug in gecko or chrome that is holding things live past shutdown.
I got the assertion on a try job, not sure if that's useful to you: https://treeherder.mozilla.org/logviewer.html#?job_id=21209253&repo=try#L10466
I just got it on Windows on shutdown as well; changing the platform to all.
OS: Mac OS X → All
1 failures in 632 pushes (0.002 failures/push) were associated with this bug in the last 7 days. Repository breakdown: * mozilla-inbound: 1 Platform breakdown: * osx-10-10: 1 For more details, see: https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1265637&startday=2018-05-21&endday=2018-05-27&tree=trunk
You need to log in before you can comment on or make changes to this bug.