1275752 - Evaluating anything in the web console leaks (and triggers fatal assert at shutdown: "Assertion failure: isEmpty() (failing this assertion means this LinkedList's creator is buggy: [...]), at LinkedList.h:332

Status: RESOLVED WORKSFORME

(DevTools :: Console, defect)

Comment 1

[Brad Werth [:bradwerth]]

Attachment: Grid3.patch

Reproduction to hit assert at https://dxr.mozilla.org/mozilla-central/source/mfbt/LinkedList.h#329:
1) Load html at /dom/grid/test/chrome/test_grid_object.html.
2) Open Web Console.
3) Force the creation of the Grid object by entering: "wrapper.grid" in the Web Console.
4) Quit Nightly. Assert will be hit during shutdown.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Is the needinfo "what does that assert mean?" or "what causes the assert"?  Some indication of what info you're looking for would be useful.

That assert typically means things leaked, if it's coming from the JS heap code.  If it's coming from somewhere else, then from where?

What leaked... well, that's a harder question.  I skimmed the patch and nothing looks obviously leaky in it...

Is this reliably reproducible?  Do you also reproduce if you execute "wrapper.grid" in a webpage, or only in the web console?

Comment 3

[Brad Werth [:bradwerth]]

Thank you. My interest is understanding what's causing the assert so I don't land bad code later. The assert is reproducible with the steps laid out, but only occurs when executed from the Web Console. The assert is not hit when the page itself accesses the wrapper.grid property (as verified in a different test not included in this patch).

Comment 4

[Boris Zbarsky [:bzbarsky]]

Andrew, do you want to take a look?  Something is fishy here, seems to me...

Brad, just to check one more thing: I assume you're doing this in e10s mode?  Do you get the same problem in non-e10s mode?

Comment 5

[Andrew McCreight [:mccr8]]

Brad, could you attach the stack for this assertion to this bug, please? That is needed to figure out who exactly is causing it, as this is fairly generic.

Comment 6

[Brad Werth [:bradwerth]]

In my testing, I have e10s turned off. I just re-enabled and reproduced the bug with e10s on. The stack traces appear identical. Here's the trace from a run where e10s was OFF:

#0	0x000000010940ac4b in mozilla::LinkedList<js::UnboxedLayout>::~LinkedList() at /Users/brad/repos/obj-mozilla-central/dist/include/mozilla/LinkedList.h:329
#1	0x00000001093e7d75 in mozilla::LinkedList<js::UnboxedLayout>::~LinkedList() at /Users/brad/repos/obj-mozilla-central/dist/include/mozilla/LinkedList.h:328
#2	0x00000001093ccfc7 in JSCompartment::~JSCompartment() at /Users/brad/repos/mozilla-central/js/src/jscompartment.cpp:115
#3	0x00000001093cd285 in JSCompartment::~JSCompartment() at /Users/brad/repos/mozilla-central/js/src/jscompartment.cpp:96
#4	0x0000000109425dd0 in void js_delete<JSCompartment>(JSCompartment const*) at /Users/brad/repos/obj-mozilla-central/dist/include/js/Utility.h:382
#5	0x000000010942e8ea in JS::Zone::sweepCompartments(js::FreeOp*, bool, bool) at /Users/brad/repos/mozilla-central/js/src/jsgc.cpp:3761
#6	0x000000010942ecf3 in js::gc::GCRuntime::sweepZones(js::FreeOp*, bool) at /Users/brad/repos/mozilla-central/js/src/jsgc.cpp:3810
#7	0x0000000109438680 in js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason) at /Users/brad/repos/mozilla-central/js/src/jsgc.cpp:6206
#8	0x0000000109438ef0 in js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason) at /Users/brad/repos/mozilla-central/js/src/jsgc.cpp:6394
#9	0x000000010943964f in js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason) at /Users/brad/repos/mozilla-central/js/src/jsgc.cpp:6502
#10	0x000000010942c966 in js::gc::GCRuntime::gc(JSGCInvocationKind, JS::gcreason::Reason) at /Users/brad/repos/mozilla-central/js/src/jsgc.cpp:6562
#11	0x000000010972d398 in JSRuntime::~JSRuntime() at /Users/brad/repos/mozilla-central/js/src/vm/Runtime.cpp:423
#12	0x000000010972da05 in JSRuntime::~JSRuntime() at /Users/brad/repos/mozilla-central/js/src/vm/Runtime.cpp:371
#13	0x00000001093ab730 in void js_delete<JSRuntime>(JSRuntime const*) at /Users/brad/repos/obj-mozilla-central/dist/include/js/Utility.h:382
#14	0x00000001093ab705 in JS_DestroyRuntime(JSRuntime*) at /Users/brad/repos/mozilla-central/js/src/jsapi.cpp:484
#15	0x00000001027e416f in mozilla::CycleCollectedJSRuntime::~CycleCollectedJSRuntime() at /Users/brad/repos/mozilla-central/xpcom/base/CycleCollectedJSRuntime.cpp:474
#16	0x0000000103a8cd0e in XPCJSRuntime::~XPCJSRuntime() at /Users/brad/repos/mozilla-central/js/xpconnect/src/XPCJSRuntime.cpp:1672
#17	0x0000000103a8d1b5 in XPCJSRuntime::~XPCJSRuntime() at /Users/brad/repos/mozilla-central/js/xpconnect/src/XPCJSRuntime.cpp:1604
#18	0x0000000103a8d1d9 in XPCJSRuntime::~XPCJSRuntime() at /Users/brad/repos/mozilla-central/js/xpconnect/src/XPCJSRuntime.cpp:1604
#19	0x0000000103afb7fd in nsXPConnect::~nsXPConnect() at /Users/brad/repos/mozilla-central/js/xpconnect/src/nsXPConnect.cpp:105
#20	0x0000000103afb835 in nsXPConnect::~nsXPConnect() at /Users/brad/repos/mozilla-central/js/xpconnect/src/nsXPConnect.cpp:77
#21	0x0000000103afb859 in nsXPConnect::~nsXPConnect() at /Users/brad/repos/mozilla-central/js/xpconnect/src/nsXPConnect.cpp:77
#22	0x0000000103afb58c in nsXPConnect::Release() at /Users/brad/repos/mozilla-central/js/xpconnect/src/nsXPConnect.cpp:42
#23	0x0000000103afba07 in nsXPConnect::ReleaseXPConnectSingleton() at /Users/brad/repos/mozilla-central/js/xpconnect/src/nsXPConnect.cpp:153
#24	0x0000000103aa0259 in xpcModuleDtor() at /Users/brad/repos/mozilla-central/js/xpconnect/src/XPCModule.cpp:22
#25	0x00000001073e6052 in LayoutModuleDtor() at /Users/brad/repos/mozilla-central/layout/build/nsLayoutModule.cpp:1385
#26	0x00000001028d2d5a in nsComponentManagerImpl::KnownModule::~KnownModule() at /Users/brad/repos/mozilla-central/xpcom/components/nsComponentManager.h:236
#27	0x00000001028d2d15 in nsComponentManagerImpl::KnownModule::~KnownModule() at /Users/brad/repos/mozilla-central/xpcom/components/nsComponentManager.h:234
#28	0x00000001028d2cda in nsAutoPtr<nsComponentManagerImpl::KnownModule>::~nsAutoPtr() at /Users/brad/repos/mozilla-central/xpcom/base/nsAutoPtr.h:78
#29	0x00000001028d2ca5 in nsAutoPtr<nsComponentManagerImpl::KnownModule>::~nsAutoPtr() at /Users/brad/repos/mozilla-central/xpcom/base/nsAutoPtr.h:77
#30	0x00000001028d3ac5 in nsTArrayElementTraits<nsAutoPtr<nsComponentManagerImpl::KnownModule> >::Destruct(nsAutoPtr<nsComponentManagerImpl::KnownModule>*) at /Users/brad/repos/obj-mozilla-central/dist/include/nsTArray.h:523
#31	0x00000001028d3a96 in nsTArray_Impl<nsAutoPtr<nsComponentManagerImpl::KnownModule>, nsTArrayInfallibleAllocator>::DestructRange(unsigned long, unsigned long) at /Users/brad/repos/obj-mozilla-central/dist/include/nsTArray.h:2014
#32	0x00000001028d39f8 in nsTArray_Impl<nsAutoPtr<nsComponentManagerImpl::KnownModule>, nsTArrayInfallibleAllocator>::RemoveElementsAt(unsigned long, unsigned long) at /Users/brad/repos/obj-mozilla-central/dist/include/nsTArray.h:1656
#33	0x00000001028ce22f in nsTArray_Impl<nsAutoPtr<nsComponentManagerImpl::KnownModule>, nsTArrayInfallibleAllocator>::Clear() at /Users/brad/repos/obj-mozilla-central/dist/include/nsTArray.h:1666
#34	0x00000001028c9a90 in nsComponentManagerImpl::Shutdown() at /Users/brad/repos/mozilla-central/xpcom/components/nsComponentManager.cpp:910
#35	0x0000000102943309 in mozilla::ShutdownXPCOM(nsIServiceManager*) at /Users/brad/repos/mozilla-central/xpcom/build/XPCOMInit.cpp:990
#36	0x0000000102942cb5 in ::NS_ShutdownXPCOM(nsIServiceManager *) at /Users/brad/repos/mozilla-central/xpcom/build/XPCOMInit.cpp:809
#37	0x0000000107d7139f in ScopedXPCOMStartup::~ScopedXPCOMStartup() at /Users/brad/repos/mozilla-central/toolkit/xre/nsAppRunner.cpp:1472
#38	0x0000000107d713e5 in ScopedXPCOMStartup::~ScopedXPCOMStartup() at /Users/brad/repos/mozilla-central/toolkit/xre/nsAppRunner.cpp:1453
#39	0x0000000107d8030b in mozilla::DefaultDelete<ScopedXPCOMStartup>::operator()(ScopedXPCOMStartup*) const at /Users/brad/repos/obj-mozilla-central/dist/include/mozilla/UniquePtr.h:528
#40	0x0000000107d8028f in mozilla::UniquePtr<ScopedXPCOMStartup, mozilla::DefaultDelete<ScopedXPCOMStartup> >::reset(ScopedXPCOMStartup*) at /Users/brad/repos/obj-mozilla-central/dist/include/mozilla/UniquePtr.h:343
#41	0x0000000107d7eaf7 in mozilla::UniquePtr<ScopedXPCOMStartup, mozilla::DefaultDelete<ScopedXPCOMStartup> >::operator=(std::nullptr_t) at /Users/brad/repos/obj-mozilla-central/dist/include/mozilla/UniquePtr.h:313
#42	0x0000000107d7bbdd in XREMain::XRE_main(int, char**, nsXREAppData const*) at /Users/brad/repos/mozilla-central/toolkit/xre/nsAppRunner.cpp:4501
#43	0x0000000107d7c047 in ::XRE_main(int, char **, const nsXREAppData *, uint32_t) at /Users/brad/repos/mozilla-central/toolkit/xre/nsAppRunner.cpp:4581
#44	0x0000000100002af2 in do_main(int, char**, char**, nsIFile*) at /Users/brad/repos/mozilla-central/browser/app/nsBrowserApp.cpp:242
#45	0x0000000100001e65 in main at /Users/brad/repos/mozilla-central/browser/app/nsBrowserApp.cpp:382
#46	0x0000000100001924 in start ()

Comment 7

[Andrew McCreight [:mccr8]]

Terrence, what does this assertion mean? Can he comment something out to figure out what is leaking?

Comment 8

[Terrence Cole [:terrence]]

That means that some JS object is leaking. The exact set of JS objects that is still live at exit should have been printed out to the terminal immediately before that crash, for use with your CC/GC log tracing tools.

Comment 9

[Brad Werth [:bradwerth]]

Console output immediately preceeding the assert is: 

  [1151] WARNING: nsAppShell::Exit() called redundantly: file /Users/brad/repos/mozilla-central/widget/cocoa/nsAppShell.mm, line 679
  [1151] WARNING: NS_ENSURE_TRUE(context) failed: file /Users/brad/repos/mozilla-central/xpcom/threads/nsThread.cpp, line 884
  [1151] WARNING: 'NS_FAILED(RemovePermissionChangeObserver())', file /Users/brad/repos/mozilla-central/dom/notification/Notification.cpp, line 692

followed by 114K lines of the form:

  ERROR: GC found live Cell 0x11a77b040 of kind FUNCTION at shutdown

After the lines with "kind FUNCTION", other kinds that appear are: FUNCTION_EXTENDED, OBJECT0, OBJECT0_BACKGROUND, OBJECT2, OBJECT2_BACKGROUND, OBJECT4, OBJECT4_BACKGROUND, OBJECT8, OBJECT8_BACKGROUND, OBJECT16, OBJECT16_BACKGROUND, SCRIPT, SHAPE, ACCESSOR_SHAPE, BASE_SHAPE, OBJECT_GROUP, FAT_INLINE_STRING, STRING, EXTERNAL_STRING.

The final line of out is the assert itself.

Comment 10

[Terrence Cole [:terrence]]

Great! It seems that that patch is working as expected.

What you'll want to do is follow the instructions at [1] to generate GC and CC log dumps. Then you'll need to use find_roots.py on those logs with some of the GC Cells in the output from the run you used to generate the logs. I'd try it on a handful or two: they should all have the same initial path. Whatever edges are common most likely contains the leak. Hopefully these edges will point us right at the leak.

1- https://developer.mozilla.org/en-US/docs/Mozilla/Performance/GC_and_CC_logs

Comment 11

[Brad Werth [:bradwerth]]

Attachment: find_roots.py analysis of gc-edges log

I ran the GC find_roots.py script on a sparse sampling of the leaked objects. To me, there does not seem to be any obvious commonality in the roots.

Comment 12

[Terrence Cole [:terrence]]

Can you make any sense of the find_roots output Brad posted?

Comment 13

[Andrew McCreight [:mccr8]]

(In reply to Brad Werth [:bradwerth] from comment #11)
> I ran the GC find_roots.py script on a sparse sampling of the leaked
> objects. To me, there does not seem to be any obvious commonality in the
> roots.

Oh, sorry, you should re-run find_roots with the -bro ("black roots only") option. That ignores CC holders and might give a better result.

Comment 14

[Brad Werth [:bradwerth]]

Attachment: find_roots.py analysis of gc-edges log, with -bro

Analysis with -bro on. The majority of leaked objects have this sequence as a common root:

0x12a028d00 [Location <no private>]
    --[ProxyObject_shape]--> 0x184d31290 [shape]
    --[base]--> 0x184d054e8 [base_shape]
    --[global]--> 0x1837b4240 [Window <no private>]
    --[**UNKNOWN SLOT 164**]--> 0x12265f790 [Block <no private>]

Comment 15

[Andrew McCreight [:mccr8]]

Hmm, so looking at the full log, I think the Location object things are also gray roots, and thus probably not what is really holding stuff alive.

The top root is this:

via persistent-Object :
0x11a572100 [Sandbox 11d254f98]
    --[**UNKNOWN SLOT 56**]--> 0x11a575d40 [Function]
    --[shape]--> 0x11a57a308 [shape]
    --[parent]--> 0x11a579158 [shape]
    --[setter]--> 0x11a57b040 [Function set caller]

Maybe the sandbox needs to be explicitly destroyed? I'm not sure how that works.

Comment 16

[Andrew McCreight [:mccr8]]

Oh but you don't add a sandbox. Maybe try running find_roots on the cc-edges file on the Location object 0x12a028d00?

Just as a side note, I don't think any of those classes you are adding need to implement nsISupports, assuming they don't inherit or are inherited from anything besides nsWrapperCache. We have support for "native" cycle collected objects that are not nsISupports.

Comment 17

[Brad Werth [:bradwerth]]

Hmm. Not sure how to proceed after this result:

$ ./find_roots.py /Users/brad/repos/logs/cc-edges.14992-2.log 0x12a028d00
Parsing /Users/brad/repos/logs/cc-edges.14992-2.log. Done loading graph. 
Didn't find a path.

On the issue of nsISupports, I'd like to remove the use of nsISupports, but https://dxr.mozilla.org/mozilla-central/source/dom/bindings/Codegen.py#12114 is putting a static assert into the generated bindings.cpp files for GridLines and GridTracks since they have the [ArrayClass] property. It seems that deriving from nsISupports is mandatory for such webIDLs.

Comment 18

[Andrew McCreight [:mccr8]]

(In reply to Brad Werth [:bradwerth] from comment #17)
> Hmm. Not sure how to proceed after this result:
Yeah, I'm not sure either. I'll try to think of something.

> On the issue of nsISupports, I'd like to remove the use of nsISupports, but
> https://dxr.mozilla.org/mozilla-central/source/dom/bindings/Codegen.py#12114
> is putting a static assert into the generated bindings.cpp files for
> GridLines and GridTracks since they have the [ArrayClass] property. It seems
> that deriving from nsISupports is mandatory for such webIDLs.

Oh, okay. I don't know anything about ArrayClass.

Comment 19

[Boris Zbarsky [:bzbarsky]]

We probably shouldn't be using ArrayClass on new things; people seem to feel it's a bad idea.

I expect devtools stuff might happen in a sandbox....

Comment 20

[Boris Zbarsky [:bzbarsky]]

Also, the [ArrayClass] is not what requires nsISupports.  It's the indexed getter that does.

Comment 21

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]: Leaking is bad.

OK, I poked at this a bit today.  I have simpler steps to reproduce this leak, I think:

1)  Take a current Firefox debug build (in my case from rev 085bacd46edf).
2)  Load about:blank.
3)  Open the Web Console.
4)  Evaluate the string "(1)".
5)  Quit the browser.

If I insert a step 4.5, closing the web console, we still leak.  Note that this has nothing to do with Grid objects, or indeed any DOM objects per se.  We leak if anything at all is evaluated in the web console, as far as I can see.  Over to devtools.

This seems rather bad.  I'm _hoping_ it's a regression and we're not shipping this to users right now....

Comment 22

[Jim Blandy :jimb]

I'm about to go on vacation for two weeks starting Saturday, and I don't think I'll be able to find time to work on this tomorrow. Nick, would you be able to look into this?

Comment 23

[Boris Zbarsky [:bzbarsky]]

For what it's worth, I'm currently bisecting this, using my steps to reproduce.  Firefox 47 does _not_ seem to be affected based on my current bisect state, which is good.  Hope to have more data soonish.

Comment 24

[Boris Zbarsky [:bzbarsky]]

The bisect keeps pointing to:

The first bad revision is:
changeset:   300580:8a44fc10f73b
user:        Jan Varga <[e-mail]>
date:        Sun Jun 05 21:43:09 2016 +0200
summary:     Bug 1195930 - Part 11: Unified SQLite database schema and storage version, major and minor version support; r=asuth

I've tried a few times and that changeset shows the problem and its parent does not.  This clearly doesn't make much sense.  :(  I guess I'll try bisecting with the original steps tomorrow...

Comment 25

[Boris Zbarsky [:bzbarsky]]

OK.  So today I made sure to use a clean profile for each run and whatnot and I'm still seeing the leak (with both my STR and the original STR in this bug) on this revision:

  changeset:   287009:68d3781deda0
  tag:         FIREFOX_AURORA_47_BASE
  parent:      286984:a75d87f4cf52
  parent:      287008:4b9a16cc88c2
  user:        Carsten "Tomcat" Book <[e-mail]>
  date:        Mon Mar 07 11:34:06 2016 +0100
  summary:     merge mozilla-inbound to mozilla-central a=merge

That means we _are_ in fact shipping this in 47 as far as I can tell.  I'm not seeing any windows or documents in the leak output, but I _am_ seeing some CSS stuff, 58 ProtoAndIfaceCache instances, 12 SandboxPrivates, lots of arrays and strings (possibly held by the CSS stuff), etc.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Attachment: Leak log from the FIREFOX_AURORA_47_BASE changeset and my steps

Comment 27

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Jim Blandy :jimb from comment #22)
> I'm about to go on vacation for two weeks starting Saturday, and I don't
> think I'll be able to find time to work on this tomorrow. Nick, would you be
> able to look into this?

I will also be going on vacation, but only for one week. I can dig in when I get back if no one else has figured it out.

Somewhat related, I observed in bug 1261869 that just opening the devtools and refreshing leaks the old window until devtools are closed. However, I hit a wall in debugging where find_roots.py couldn't find any CC roots for expandos that the CC was marking as GC roots.

Comment 28

[Justin [:JW_SoftvisionQA]]

Regression window was provided in Comment 25

Comment 29

[Boris Zbarsky [:bzbarsky]]

> Regression window was provided in Comment 25

No, it wasn't.  All comment 25 says is that the base revision for Firefox 47 branch leaks.  We have no idea how far back the leak goes.

Comment 30

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

It's hard to tell the extent of the leak, whether it is a fixed leak or a leak that grows over time. So far since Fx47 went live, there haven't been any complaints from end-users about memleaks. Based on that I do not think this is critical enough to include in a or drive a dot release.

Tracked for 48+

Comment 31

[Jim Blandy :jimb]

It would be a big help to get an exact regression window. Devtools doesn't have a QA lead. I'll talk to RyanVM to see if his group could help us get this set up.

Comment 32

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Boris Zbarsky [:bz] (Out June 25-July 6) from comment #21)
> [Tracking Requested - why for this release]: Leaking is bad.
> 
> OK, I poked at this a bit today.  I have simpler steps to reproduce this
> leak, I think:
> 
> 1)  Take a current Firefox debug build (in my case from rev 085bacd46edf).
> 2)  Load about:blank.
> 3)  Open the Web Console.
> 4)  Evaluate the string "(1)".
> 5)  Quit the browser.
> 
> If I insert a step 4.5, closing the web console, we still leak.  Note that
> this has nothing to do with Grid objects, or indeed any DOM objects per se. 
> We leak if anything at all is evaluated in the web console, as far as I can
> see.  Over to devtools.
> 
> This seems rather bad.  I'm _hoping_ it's a regression and we're not
> shipping this to users right now....

With these STR, how do I know whether I reproduced the leak or not? Am I looking for a ~LinkedList assertion failure as in comment 0, or am I looking for a bloat view table logged to the terminal? Or something else?

Comment 33

[Boris Zbarsky [:bzbarsky]]

> It would be a big help to get an exact regression window.

At the moment, I have no evidence that this is actually a regression...  Then again, I have not tested anything older than the Firefox 47 branchpoint, so it's possible that it is, just before then sometime.

> With these STR, how do I know whether I reproduced the leak or not? 

With the comment 21 str, what I observe at shutdown (on Mac) is tens of thousands of lines of printout from the JS engine saying that various stuff leaked, followed by the ~LinkedList assertion.  There is no bloat view table, because the ~LinkedList assertion kills us before we get to logging one.

The leak log in comment 26 was generated by commenting out the assertion so we can actually get the bloat view table and then performing the steps from comment 21 with XPCOM_MEM_LEAK_LOG=/tmp/log.txt set in the environment.

Comment 34

[Daniel Holbert [:dholbert]]

[Adding the LinkedList assertion text to the bug summary, for better searchability / fewer accidental dupes like bug 1279351]

Comment 36

[Gerry Chang [:gchang]]

Hi Florin,
Is possible that you can have someone to help us to find the regression window?

Comment 37

[Andrei Vaida [:avaida]]

Added to my team's todo list, we'll follow up as soon as possible.

Comment 38

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

I managed to manually look for a regression range. Due to time reasons and because there are many debug builds in a single day, I couldn't perform a deeper one. I have used Mac OS X 10.11, Mac OS X 10.10.4 and debug builds between 2015-09-21 and 2016-08-23, available on tinderbox-builds. These are the results:
- between 50.0a2 (2016-08-23) 20160823021946 and 49.0a2 (2016-07-03) 20160703120757, the issue is not reproducible anymore (there is no ~LinkedList assertion triggered);
- between 49.0a2 (2016-07-01) 20160701064957 and 49.0a2 (2016-06-06) 20160606184929, "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 /builds/slave/m-aurora-m64-d-000000000000000/build/src/obj-firefox/dist/include/mozilla/LinkedList.h:332" is displayed, preceded by thousands of "ERROR: GC found live Cell~ at shutdown";
- between 48.0a2 (2016-06-05) 20160605010644 and (2016-03-07) 47.0a2 20160307152238, "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 /builds/slave/m-aurora-m64-d-000000000000000/build/src/obj-firefox/dist/include/mozilla/LinkedList.h:332" is displayed, but without GC errors;
- between 46.0a2 (2016-03-06) 20160306230438 and 44.0a2 (2015-10-29) 20151029094226, "Assertion failure: isEmpty(), at ../../dist/include/mozilla/LinkedList.h:328" is displayed, but without GC errors;
- between 43.0a2 (2015-10-28) 20151028131431 and 43.0a2 (2015-09-22) 20150922131735, "Assertion failure: isEmpty(), at ../../dist/include/mozilla/LinkedList.h:308" is displayed, without GC errors;
- on 42.0a2 20150921042234, the issue is not reproducible anymore (there is no ~LinkedList assertion triggered).

Comment 39

[Boris Zbarsky [:bzbarsky]]

1) The "ERROR: GC found" message was only added recently.  Older builds won't show it even if there is live stuff at shutdown.  That's why you don't see it with the 47 and earlier builds.

2) The LinkedList assertion not being reproducible on older builds may simply mean that there is no LinkedList there.

The right way to check for leaks is to do an actual leak log and see whether there was a leak...

Comment 40

[Terrence Cole [:terrence]]

Well, it does show that the issues is probably gone after 49.0a2. \o/

Comment 41

[Boris Zbarsky [:bzbarsky]]

Could be.  I'd be _really_ interested in a narrower range than that, so we can make sure it's really fixed and not just masked...

Comment 42

[Jim Blandy :jimb]

I don't have anything I can contribute to this bug at the moment, unless I actually assign it to myself and take on fixing it, so I'm clearing the needinfo for now.

Comment 43

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for 49; I don't think we are close to any solution here and this doesn't look like it should block the release. Maybe it is fixed but until someone has time to investigate again, we don't know.

Comment 44

[Daniel Holbert [:dholbert]]

Based on comment 40 (and first bullet-point of comment 38), I think this should be WORKSFORME, then?

(bradwerth, you reported this -- can you still reproduce this?)

Comment 45

[Brad Werth [:bradwerth]]

Can no longer reproduce. I tried to reproduce on mozilla-central da986c9f1f72 using bz's technique in comment 21 and there was no assertion in either e10s mode or single process mode.

Comment 46

[Julien Cristau [:jcristau] (back April 22)]

Wontfix for 50, as it's too late now (and it's not even clear the bug is still there).