Closed
Bug 78861
Opened 24 years ago
Closed 12 years ago
###!!! ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == 0'
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
INCOMPLETE
Future
People
(Reporter: timeless, Unassigned)
References
()
Details
(Keywords: assertion, topembed+, Whiteboard: edt_b3)
Attachments
(4 files)
1.21 KB,
patch
|
dmosedale
:
review+
scc
:
superreview+
|
Details | Diff | Splinter Review |
8.88 KB,
patch
|
Details | Diff | Splinter Review | |
58.55 KB,
application/x-gzip
|
Details | |
9.77 KB,
text/plain
|
Details |
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...
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•24 years ago
|
||
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•23 years ago
|
||
*** Bug 134601 has been marked as a duplicate of this bug. ***
Comment 4•23 years ago
|
||
platform+os -> all per dup & my own experience
OS: Solaris → All
Hardware: Sun → All
Comment 5•23 years ago
|
||
*** Bug 133962 has been marked as a duplicate of this bug. ***
Comment 6•23 years ago
|
||
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 9•23 years ago
|
||
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.
Attachment #89735 -
Flags: review+
Comment 10•23 years ago
|
||
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
Attachment #89735 -
Flags: superreview+
Comment 11•23 years ago
|
||
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.
Attachment #89735 -
Flags: needs-work+
Comment 12•22 years ago
|
||
i am going to fix this up.
Assignee: shaver → dougt
Target Milestone: --- → mozilla1.4beta
Updated•22 years ago
|
Whiteboard: edt_b3
Comment 13•22 years ago
|
||
mid air collision with valeski trying to topembed plus this bug. Adding that change for him
Keywords: topembed+
Comment 14•22 years ago
|
||
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 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Actually, once I'm not using the Java plugin anymore, I don't see the leaked wrapper related to the JS components either.
(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•22 years ago
|
||
I also see a leak without either js components or Java installed when you press the "exit" button on the profile manager dialog.
Comment 22•22 years ago
|
||
I just filed a bug again the profile manager front end. 198654
Depends on: 198654
Comment 23•22 years ago
|
||
I just filed a seperate bug on the js component - component manager leak 198655.
Depends on: 198655
Comment 25•19 years ago
|
||
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
Updated•19 years ago
|
Assignee: dougt → nobody
Status: REOPENED → NEW
QA Contact: scc → xpcom
Comment 26•16 years ago
|
||
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•13 years ago
|
||
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.
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 22 years ago → 12 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•