Last Comment Bug 78861 - ###!!! ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == 0'
: ###!!! ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == 0'
Status: RESOLVED INCOMPLETE
edt_b3
: assertion, topembed+
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://bonsai.mozilla.org/cvsblame.cg...
: 133962 134601 (view as bug list)
Depends on: 180380 198647 198654 198655 199465 200030 201067
Blocks: qt 160540 762549
  Show dependency treegraph
 
Reported: 2001-05-04 00:13 PDT by timeless
Modified: 2013-02-15 10:56 PST (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix [-uw] xpcshell (1.21 KB, patch)
2002-06-30 15:10 PDT, timeless
dmose: review+
scc: superreview+
Details | Diff | Splinter Review
same patch, -u (8.88 KB, patch)
2002-06-30 15:57 PDT, timeless
no flags Details | Diff | Splinter Review
balance tree showing leaks caused by Java plugin (58.55 KB, application/x-gzip)
2003-03-21 08:05 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details
balance tree showing leaks caused by Java plugin (9.77 KB, text/plain)
2003-03-21 08:07 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details

Description timeless 2001-05-04 00:13:05 PDT
y:/tmp/obj-sparc-sun-solaris2.7/dist/bin: ./mozilla -splash
./run-mozilla.sh ./mozilla-bin -splash
MOZILLA_FIVE_HOME=.
  LD_LIBRARY_PATH=.:./plugins:/tmp/idl/lib:/tmp/glib/lib:/tmp/qt-2.2.0/lib
     LIBRARY_PATH=.:./components
       SHLIB_PATH=.
          LIBPATH=.
       ADDON_PATH=.
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=

Oh, right, here's the crash from regxpcom
WARNING: nsJSRuntimeService is missing, file 
/tmp/mozilla/modules/libpref/src/nsPrefService.cpp, line 719
Runtime mismatch, so leaking context!
JS API usage error: 1 contexts left in runtime upon JS_DestroyRuntime.
JS engine warning: 27 atoms remain after destroying the JSRuntime.
                   These atoms may point to freed memory. Things reachable
                   through them have not been finalized.
JS engine warning: leaking GC root 'res->input' at 151fe8
JS engine warning: 1 GC root remains after destroying the JSRuntime.
                   This root may point to freed memory. Objects reachable
                   through it have not been finalized.
###!!! ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == 
0', file /tmp/mozilla/xpcom/build/nsXPComInit.cpp, line 505
###!!! Break: at file /tmp/mozilla/xpcom/build/nsXPComInit.cpp, line 505
###!!! ASSERTION: nsDOMEvent not thread-safe: 'owningThread == 
NS_CurrentThread()', file /tmp/mozilla/xpcom/base/nsDebug.cpp, line 528
###!!! Break: at file /tmp/mozilla/xpcom/base/nsDebug.cpp, line 528

Bugs are filed for everything else, i think...
Comment 1 Ken 2001-05-20 07:09:22 PDT
I occasionally see the "Component Manager being held past XPCOM shutdown" 
assertion, although it doesn't cause a crash under win2k. Any progress or 
further information on the cause of this issue?
Comment 2 John Bandhauer 2001-06-12 20:04:01 PDT
My experience is that the holding of the ref is a side effect of the shutdown
ordering between the xpconnect module and the JS component loader module.
xpconnect is shutting down first and for reasons too painful to mention it does
not automatically do a Release on the wrapped native component manager which it
renders uncallable from JS code.

There is work afoot to combine the xpconnect and JS component loader modules.
I'm not sure this would by itself fix things. There is the question of the
proper ordering between the shutdown of the set of component loaders (currently
only the native, JS, and Python loaders in our tree) and the modules loaded by
the native component loader (such as xpconnect).

I sometimes wonder if the assert is necessary. Yes, it is odd that references
are held, and any calls made to it after this point ought to return error codes.
but is it really so evil to hold the reference? I mostly think it *is* evil. But
I wonder if it much matters.
Comment 3 Doug Turner (:dougt) 2002-04-01 16:00:34 PST
*** Bug 134601 has been marked as a duplicate of this bug. ***
Comment 4 Christian :Biesinger (don't email me, ping me on IRC) 2002-04-30 13:29:50 PDT
platform+os -> all per dup & my own experience
Comment 5 Asa Dotzler [:asa] 2002-06-25 18:46:24 PDT
*** Bug 133962 has been marked as a duplicate of this bug. ***
Comment 6 Jesse Ruderman 2002-06-25 20:52:47 PDT
Since this assertion has been around for a year and happens every time I exit a
debug build, can it be changed so that only certain people see the assertion?
Comment 7 timeless 2002-06-30 15:10:01 PDT
Created attachment 89735 [details] [diff] [review]
fix [-uw] xpcshell
Comment 8 timeless 2002-06-30 15:57:09 PDT
Created attachment 89737 [details] [diff] [review]
same patch, -u
Comment 9 Dan Mosedale (:dmose) 2002-06-30 16:09:44 PDT
Comment on attachment 89735 [details] [diff] [review]
fix [-uw] xpcshell

r=dmose, with the addition of the bracing comment that we talked about in irc.
Comment 10 Scott Collins 2002-06-30 16:15:41 PDT
Comment on attachment 89735 [details] [diff] [review]
fix [-uw] xpcshell

sr=scc, including the comment fix as requested by dmose, and the removal of the
|nsnull| assignments into |nsCOMPtr|s scheduled for destruction immediately
afterwards anyway
Comment 11 John Bandhauer 2002-06-30 22:16:37 PDT
Comment on attachment 89735 [details] [diff] [review]
fix [-uw] xpcshell

This patch has nothing to do with the reported problem (an assertion when
running the mozilla executable). There is ZERO discussion in the bug to talk
about what the patch does or why it might be a good thing. If all you are
trying to do is releae the service manager at a specific time then why not add
a line to just null it out?

The real problem is about the JS component system holding onto the SM too long.
Not about the xpcshell.

Also note that module owner approval would be necessary before checkin. I don't
care *who* you corner on IRC.
Comment 12 Doug Turner (:dougt) 2003-03-04 13:52:34 PST
i am going to fix this up.
Comment 13 Michael Buckland 2003-03-19 16:56:15 PST
mid air collision with valeski trying to topembed plus this bug.  Adding that
change for him
Comment 14 Doug Turner (:dougt) 2003-03-19 21:24:26 PST
dbaron has been doing some work to fix the problem jband mentioned in comment 11.

marking this bug dup of 180380

*** This bug has been marked as a duplicate of 180380 ***
Comment 15 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-03-21 08:03:43 PST
I'm going to reopen this.  The leaks of the component manager are separate from
the leaks of the nsXPCComponents object.  (I can fix the former without fixing
the latter.)

In particular, I see three references to the component manager leaked in my build.
 * one is a reference held by an XPCWrappedNative, related to the presence of
some JS component.  When I move all the JS components out of the components
directory, this leaked reference goes away.
 * The other two are related to the Java plugin, which leaks two references to
the component manager.  I'll attach a refcount balancer tree showing these leaks.
Comment 16 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-03-21 08:05:57 PST
Created attachment 118024 [details]
balance tree showing leaks caused by Java plugin
Comment 17 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-03-21 08:07:36 PST
Created attachment 118025 [details]
balance tree showing leaks caused by Java plugin
Comment 18 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-03-21 08:18:41 PST
Actually, once I'm not using the Java plugin anymore, I don't see the leaked
wrapper related to the JS components either.
Comment 19 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-03-21 08:23:30 PST
(But actually, seeing the world as this leak-free with JS components requires
having attachment 117847 [details] [diff] [review] in your tree.  Otherwise I do leak the component
manager even without the Java plugin, along with a whole bunch of other stuff.)
Comment 20 Doug Turner (:dougt) 2003-03-21 10:00:44 PST
I also see a leak without either js components or Java installed when you press
the "exit" button on the profile manager dialog.
Comment 21 Doug Turner (:dougt) 2003-03-21 12:51:23 PST
I filed a bug against the jre 198647
Comment 22 Doug Turner (:dougt) 2003-03-21 12:59:14 PST
I just filed a bug again the profile manager front end. 198654
Comment 23 Doug Turner (:dougt) 2003-03-21 13:04:52 PST
I just filed a seperate bug on the js component - component manager leak 198655.
Comment 24 Doug Turner (:dougt) 2003-06-09 08:37:40 PDT
meta bug -> futuring.
Comment 25 François Gagné 2006-02-18 12:02:06 PST
I'm hitting this assertion everytime I start and shutdown Firefox on 1.5 Branch,
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060217 Firefox/1.5

###!!! ASSERTION: Main thread being held past XPCOM shutdown.: 'cnt == 0', file f:/cygwin/home/root/mozilla/mozilla/xpcom/threads/nsThread.cpp, line 478
Comment 26 Carsten Book [:Tomcat] - PTO-back Sept 4th 2009-01-26 14:05:32 PST
also happened with a recent build during the topsite test on http://www.robotjamgames.com

###!!! ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == 0',
 file c:/work/mozilla/builds/1.9.1/mozilla/xpcom/build/nsXPComInit.cpp, line 864

xul!ScopedXPCOMStartup::~ScopedXPCOMStartup+0x000000000000006E (c:\work\mozilla\
builds\1.9.1\mozilla\toolkit\xre\nsapprunner.cpp, line 951)
xul!XRE_main+0x0000000000002F9E (c:\work\mozilla\builds\1.9.1\mozilla\toolkit\xr
e\nsapprunner.cpp, line 3325)
firefox!NS_internal_main+0x00000000000002B2 (c:\work\mozilla\builds\1.9.1\mozill
a\browser\app\nsbrowserapp.cpp, line 156)
firefox!wmain+0x0000000000000119 (c:\work\mozilla\builds\1.9.1\mozilla\toolkit\x
re\nswindowswmain.cpp, line 87)
firefox!__tmainCRTStartup+0x00000000000001A6 (f:\sp\vctools\crt_bld\self_x86\crt
\src\crtexe.c, line 594)
firefox!wmainCRTStartup+0x000000000000000D (f:\sp\vctools\crt_bld\self_x86\crt\s
rc\crtexe.c, line 414)
kernel32!RegisterWaitForInputIdle+0x0000000000000049
Comment 27 Gregory Szorc [:gps] 2011-09-26 23:10:28 PDT
I managed to grab a dump file for a similar stack trace as comment #26. Error happened on m-c 77594:1f800c226837 (2011-06-26 tip) when closing Nightly after a browsing session.

Let me know if the dump file will be helpful.

Note You need to log in before you can comment on or make changes to this bug.