[MLK] nsComponentManager not getting released

RESOLVED FIXED in M12

Status

()

P2
major
RESOLVED FIXED
19 years ago
19 years ago

People

(Reporter: dveditz, Assigned: shaver)

Tracking

Trunk
x86
Windows NT
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

In NS_ShutdownXPCOM() the global component manager has a refcount of 3, of
which 1 is released leaving the object alive. Among other things this leaves
the registries open.

Updated

19 years ago
Assignee: dp → shaver

Comment 1

19 years ago
These are references from jsloader. Shaver knows.

Shaver also remember to remove the ifdef DEBUG_shaver from
xpcom/build/nsInitXPCom.cpp

Updated

19 years ago
Blocks: 14516

Updated

19 years ago
QA Contact: beppe → dp
Is this still an issue?

Comment 3

19 years ago
Last I saw yes. I fixed the servicemanager ones. The only one left is the
componentmanager being held by js component.
Assignee: shaver → dp
Yeah, but we need either:
- a weak XPConnect wrapper for the Component Manager, or
- the UnloadAll call from NS_ShutdownXPCOM
in order for this problem to be fixed; the JS loader can't get rid of JS
component references to the component manager without being told to.  I prefer
the latter for this case, because not all language bindings will have weak
reference support, and so I'm reassigning to dp.

Updated

19 years ago
Assignee: dp → shaver

Comment 5

19 years ago
I did hookin the unload call. The jscomponent loader should be getting the
unload call.

Is that all you were looking for ? Reassign back to me if there is more you
want.
Severity: normal → major
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M11
Apparently, I'm looking to update my tree.  Ulp, how embarrassing.  Sorry.
I updated my tree, and my loader never gets told to unload if it actually
constructs a JS component (which would result in an additional ref on the
component manager).  What was your change?

Comment 8

19 years ago
Here is the code from nsComponentManager.cpp that would call canunload on all
non-native loaders. Native loader is unloaded separately. Of course, this aint
tests.


// Private implementation of unloading libraries
nsresult
nsComponentManagerImpl::UnloadLibraries(nsIServiceManager *serviceMgr, PRInt32
aWhen)
{
    nsresult rv = NS_OK;

    PR_EnterMonitor(mMon);

    PR_LOG(nsComponentManagerLog, PR_LOG_ALWAYS,
           ("nsComponentManager: Unloading Libraries."));

    // UnloadAll the loaders
    /* iterate over all known loaders and ask them to autoregister. */
    struct CanUnload_closure closure;
    closure.when = aWhen;
    closure.status = NS_OK;
    closure.native = mNativeComponentLoader;
    mLoaders->Enumerate(CanUnload_enumerate, &closure);
Correct me if I'm wrong, but that code will only get called from the
nsComponentManagerImpl destructor, which requires a 0 refcount, which is the
problem I thought we were fixing.  (And, in fact, my JS loader _does_ see an
unload call if it never grabs a ref to the component manager.)

Shouldn't this call be driven from NS_ShutdownXPCOM directly?

Comment 10

19 years ago
You are correct. I was somehow assuming that you would fix the jsloader that
would make this call happen. I guess that would be checked and egg.

So what, you want the jsloaders::UnloadAll() to be released on say
nsComponentManager::Shutdown() on which you would release componentmanager
reference. If that is the agreement, assign it back to me. I will fix it and
send it your way.
Assignee: shaver → dp
Status: ASSIGNED → NEW
Yeah, that's what I want.

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 12

19 years ago
I added shutdown and now that calls into jsloader. I get this coredump though
when the jsloader is releasing the wrapped object. Lock seems spurious. Any idea
why this is happening.

(gdb) bt
#0  0x4029c111 in ?? () from /lib/libc.so.6
#1  0x4029d447 in ?? () from /lib/libc.so.6
#2  0x401b1684 in PR_Assert (s=0x401df7ea "0 == rv", file=0x401df7e0
"ptsynch.c", ln=168) at prlog.c:449
#3  0x401cb1ac in PR_Lock (lock=0x8068460) at ptsynch.c:168
#4  0x40081237 in js_RemoveRoot (rt=0x809a5c8, rp=0x81277e8) at jsgc.c:178
#5  0x40056498 in JS_RemoveRoot (cx=0x80aa678, rp=0x81277e8) at jsapi.c:1019
#6  0x405b33fc in nsXPCWrappedJS::~nsXPCWrappedJS (this=0x81277e0, __in_chrg=3)
at xpcwrappedjs.cpp:251
#7  0x405b2ea2 in nsXPCWrappedJS::Release (this=0x81277e0) at
xpcwrappedjs.cpp:93
#8  0x405d45db in Release_enumerate (he=0x8127818, cnt=0, arg=0x0) at
mozJSComponentLoader.cpp:94
#9  0x4019b271 in ?? () from /home/dp/build.debug/mozilla/dist/bin/libplds3.so
#10 0x405d4694 in mozJSComponentLoader::~mozJSComponentLoader (this=0x8067408,
__in_chrg=3) at mozJSComponentLoader.cpp:111
#11 0x405d4880 in mozJSComponentLoader::Release (this=0x8067408) at
mozJSComponentLoader.cpp:135
#12 0x40124fc6 in _ReleaseElement (aKey=0x8067da8, aData=0x8067408, closure=0x0)
at nsHashtable.cpp:383
#13 0x40124516 in _hashEnumerate (he=0x8098ef0, i=0, arg=0xbffff934) at
nsHashtable.cpp:85
#14 0x4019b271 in ?? () from /home/dp/build.debug/mozilla/dist/bin/libplds3.so
#15 0x401249cc in nsHashtable::Enumerate (this=0x8053c08, aEnumFunc=0x40124f9c
<_ReleaseElement(nsHashKey *, void *, void *)>, closure=0x0) at
nsHashtable.cpp:214
#16 0x4012500d in nsSupportsHashtable::~nsSupportsHashtable (this=0x8053c08,
__in_chrg=3) at nsHashtable.cpp:389
#17 0x4014b61a in nsComponentManagerImpl::Shutdown (this=0x80531a0) at
nsComponentManager.cpp:289
#18 0x4011e64e in NS_ShutdownXPCOM (servMgr=0x0) at nsXPComInit.cpp:484
#19 0x804bafd in main (argc=3, argv=0xbffffa14) at nsAppRunner.cpp:742
#20 0x40295cb3 in ?? () from /lib/libc.so.6

Comment 13

19 years ago
I will checkin my changes with shutdown ifdeffed DEBUG_shaver and reassign the
bug to you.

The js runtime seems to have had its lock trashed.

shaver, After you fix it turn remove DEBUG_shaver code from NS_ShutdownXPCOM()

Updated

19 years ago
Assignee: dp → shaver
Status: ASSIGNED → NEW

Comment 14

19 years ago
(wierd! I am donig this for the second time).

I checked my code in. You need to fix the js coredump on first run shutdown and
enable the code for the world. Right now it is ifdeffed DEBUG_shaver ||
DEBUG_dp

Comment 15

19 years ago
*** Bug 15387 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
The crash is probably because JS_Shutdown has already run, when the
JSRuntimeService got released.  XPConnect and the DOM need to keep that service
referenced until they shut down; I'll hack up a patch for that tonight.

Updated

19 years ago
Target Milestone: M11 → M12

Comment 17

19 years ago
m12.  let me know if fix becomes available in the next couple of days.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.