1303637 - Profile manager leaking JS runtime

Status: NEW

(Toolkit :: Startup and Profile System, defect, P5)

Description

[Jorg K (CEST = GMT+2)]

Run a debug build of Firefox (or Thunderbird) with -p to start the profile manager. Select a profile and press start. You see:

WARNING: YOU ARE LEAKING THE WORLD (at least one JSRuntime and everything alive inside it, that is) AT JS_ShutDown TIME.  FIX THIS!
[5444] WARNING: '!compMgr', file c:/mozilla-source/mozilla-central/xpcom/glue/nsComponentManagerUtils.cpp, line 63
Leaked URLs:
  chrome://mozapps/content/profile/profileSelection.xul
  resource://gre-resources/counterstyles.css
  chrome://global/content/minimal-xul.css
  resource://gre-resources/quirk.css
  resource://gre/res/svg.css
  chrome://global/content/xul.css
  chrome://global/skin/scrollbars.css
  resource://gre-resources/number-control.css

I'm not including the entire list that takes many seconds to pass on the debug console.

I mentioned this in bug 1303078 and Gijs asked:

> right now I have no idea if this shows up when you open the 
> profile manager, when you close it, or when you close 
> thunderbird or firefox or anything else after you open
> a profile from the profile manager, or something else still.
> It's also not clear if it reproduces with a clean profile on
> an official debug build, or just locally

As stated: After selecting a profile and pressing "Start".

Bug happens regardless of which profile you pick, even if you create a new profile and pick it.

I'm using my local (debug) build, I haven't tried an official debug build, but I can't imagine a reason why it should be different.

Comment 1

[ISHIKAWA, Chiaki]

ＩIn the short run, the following should fix the problem with GCC.
diff --git a/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp
b/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp
--- a/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp
+++ b/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp
@@ -113,18 +113,18 @@ invoke_copy_to_stack(uint64_t * d, uint3
 #pragma GCC target ("no-avx")
 #endif

 // Avoid AddressSanitizer instrumentation for the next function because it
 // depends on __builtin_alloca behavior and alignment that cannot be relied on
 // once the function is compiled with a version of ASan that has dynamic-alloca
 // instrumentation enabled.

+EXPORT_XPCOM_API(nsresult)
 MOZ_ASAN_BLACKLIST
-EXPORT_XPCOM_API(nsresult)
 NS_InvokeByIndex(nsISupports * that, uint32_t methodIndex,
                  uint32_t paramCount, nsXPTCVariant * params)
 {
     uint32_t nr_stack;
     invoke_count_words(paramCount, params, nr_stack);

     // Stack, if used, must be 16-bytes aligned
     if (nr_stack)

Comment 2

[Jorg K (CEST = GMT+2)]

After landing of bug 1276669 this has now become:

WARNING: YOU ARE LEAKING THE WORLD (at least one JSRuntime and everything alive
inside it, that is) AT JS_ShutDown TIME.  FIX THIS!
[4124] WARNING: '!compMgr', file c:/mozilla-source/mozilla-central/xpcom/compone
nts/nsComponentManagerUtils.cpp, line 63
[4124] ###!!! ASSERTION: dynamic atom with non-zero refcount stringBundleBinding
s!: 'false', file c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp, li
ne 397
[4124] ###!!! ASSERTION: dynamic atom with non-zero refcount no-bar!: 'false', f
ile c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp, line 397
[4124] ###!!! ASSERTION: dynamic atom with non-zero refcount autocomplete-richli
stbox!: 'false', file c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp
, line 397
[4124] ###!!! ASSERTION: dynamic atom with non-zero refcount buttonBindings!: 'f
alse', file c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp, line 397

[4124] ###!!! ASSERTION: dynamic atom with non-zero refcount autocomplete-result
-popupset!: 'false', file c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable
.cpp, line 397
[4124] ###!!! ASSERTION: dynamic atom with non-zero refcount outset!: 'false', f
ile c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp, line 397
[4124] ###!!! ASSERTION: dynamic atom with non-zero refcount dialogBindings!: 'f
alse', file c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp, line 397

[4124] ###!!! ASSERTION: dynamic atom with non-zero refcount extra2!: 'false', f
ile c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp, line 397
[4124] ###!!! ASSERTION: dynamic atom with non-zero refcount arrowbox!: 'false',
 file c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp, line 397
[4124] ###!!! ASSERTION: dynamic atom with non-zero refcount panelopen!: 'false'
, file c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp, line 397
[4124] ###!!! ASSERTION: dynamic atom with non-zero refcount preference!: 'false
', file c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp, line 397
[4124] ###!!! ASSERTION: dynamic atom with non-zero refcount More Info!: 'false'
, file c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp, line 397

Comment 3

[ISHIKAWA, Chiaki]

(In reply to ISHIKAWA, Chiaki from comment #1)
> ＩIn the short run, the following should fix the problem with GCC.

Sorry, I did not realize that I posted this to a wrong bugzilla. Only today I realized I posted this here instead of Bug 1272498

Comment 4

[Nathan Froyd [:froydnj]]

(In reply to Jorg K (GMT+1) from comment #2)
> After landing of bug 1276669 this has now become:
> 
> WARNING: YOU ARE LEAKING THE WORLD (at least one JSRuntime and everything
> alive
> inside it, that is) AT JS_ShutDown TIME.  FIX THIS!
> [4124] WARNING: '!compMgr', file
> c:/mozilla-source/mozilla-central/xpcom/compone
> nts/nsComponentManagerUtils.cpp, line 63
> [4124] ###!!! ASSERTION: dynamic atom with non-zero refcount
> stringBundleBinding
> s!: 'false', file
> c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp, li
> ne 397
> [4124] ###!!! ASSERTION: dynamic atom with non-zero refcount no-bar!:
> 'false', f
> ile c:/mozilla-source/mozilla-central/xpcom/ds/nsAtomTable.cpp, line 397

Yes, this is not particularly surprising: if we were already leaking a JSRuntime, we were almost certainly leaking atoms connected to that runtime in some fashion.

Comment 5

[Jorg K (CEST = GMT+2)]

Yes, it's not surprising. The question is whether you're going to address this problem so the TB team can learn from your approach to fix a similar-looking problem in TB.

Comment 6

[aleth [:aleth]]

(In reply to Jorg K (GMT+1) from comment #5)
> Yes, it's not surprising. The question is whether you're going to address
> this problem so the TB team can learn from your approach to fix a
> similar-looking problem in TB.

There are previous shutdown leak fixes even in c-c if you are looking for potentially useful examples, e.g. bug 765074, bug 764742, bug 955563, bug 955236.

Comment 7

[Jorg K (CEST = GMT+2)]

Boy, that's interesting reading, and somewhat frustrating too, since those leaks are hard to find.