bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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 LinkedList.h:332

NEW
Unassigned

Status

()

Core
JavaScript Engine
2 years ago
2 months ago

People

(Reporter: Tomcat, Unassigned)

Tracking

(Blocks: 1 bug, {assertion})

49 Branch
x86_64
All
assertion
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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!
(Reporter)

Updated

2 years ago
Flags: needinfo?(nfroyd)
Flags: needinfo?(jwalden+bmo)
(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.
Flags: needinfo?(nfroyd)
(Reporter)

Comment 2

2 years ago
bc, do you have a stack? the log i saw didn't generated one, but you might have more insight to get a stack
Flags: needinfo?(bob)

Comment 3

2 years ago
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.
Flags: needinfo?(bob)

Comment 4

2 years ago
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.  :-)
Flags: needinfo?(jwalden+bmo)

Comment 5

2 years ago
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

Updated

2 years ago
Component: General → XPCOM

Updated

2 years ago
See Also: → bug 739682
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
Component: XPCOM → JavaScript Engine
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.
Flags: needinfo?(terrence)
(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.
Flags: needinfo?(terrence)
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

Updated

2 years ago
Depends on: 1309662
Duplicate of this bug: 1321940
Duplicate of this bug: 1322268
I just got it on Windows on shutdown as well; changing the platform to all.
OS: Mac OS X → All
Duplicate of this bug: 1282442

Comment 14

2 months ago
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.