45613 - dll unloading is disabled

Status: RESOLVED DUPLICATE of bug 60709

(Core :: XPCOM, defect, P3)

Description

[John Bandhauer]

The code in nsFreeLibrary has the section for dll unloading commented out. The 
code comment implies that this is due to some dlls improperty claiming the 
ability to be unloadable. The dlls should be fixed and this code reenabled. 
Otherwise we'll *never* be able to turn this code on with 'broken' dlls from us 
and others proliferating.

Also, the generic module macros we all use don't seem to support overriding the 
'canUnload' method.

Safe module unloading requires that the module do a perfect job of tracking 
outstanding object instances and any other references to code in that module. I 
believe that we currently have no modules at all that even attempt this.

Do we seriously plan to ever support module unloading? If so we should verify 
that all our dlls are not falsly claiming unloadability and then turn it on in 
the component loader.

Comment 1

[Braden]

To say that unloadable modules must "perfect job of tracking 
outstanding object instances and any other references to code in that module"
seems a bit heavy-handed, and probably impossible to implement. An unloadable
module has to be able to trust that its clients are properly AddRef'ing (and
Releasing) the objects it "owns".

Comment 2

[John Bandhauer]

I stand by what I said. There is nothing else in the system to track if there 
are live references into any code that lives in a given dll. As far as the dll 
knowing when it is safe to be unloaded goes, it is necessary but not suffienct 
that the object users do correct reference counting. Of course the dll has to 
trust callers to not cheat in their reference counting (we have code that does 
cheat!). But the dll also has to keep a count of live objects. Otherwise how 
would the dll know the objects had all been released? Tracking object creation 
counts is easily done by the factories, but to track destruction the objects 
themselves need to have some extra code. This can be done via threadsafe 
accesses to a dll scoped static counter. But, it would be bad to add this code 
to the dtors of objects in any module that has no intention of being unloadable. 
Unloadable modules also need to take pains to be sure that they hand out no 
pointers to functions, static data, or the like.

While we have a long term goal of making this all work - and of polling the 
modules now and then to see if any are ready for unloading - I suspect that dp 
decided to blow this off for now. There are some scary issues about whacking the 
service manager and component managers' caches of services and factories just so 
the module can know if the object counts go to zero. Locking up the component 
manager while polling the modules would be required too. There is a serious 
amount of work that would have to be done to make unloading safe.

Still, I think it makes sense to fix the native component loader and any broken 
dlls so that if we do turn this on in the future there will be a chance that 
previously working dlls will not cause us crashes when faced with a loader that 
believes their claims of unloadability. We might still have to hardcode the 
loader at some point in time to not try to unload module x and y regardless of 
what they say. We are still enjoying the period where legacy xpcom modules are 
not floating around and we have control over the exact set of dlls that get 
installed on a system. After a few releases and more third party modules become 
available things will change. It is going to get messier before it gets better.

Comment 3

[Braden]

Whether the module has to keep track of every new'd object depends on the
ownership model within the module. For instance, a class object is going to stay
around for as long as all of its associated instances, so accounting would only
have to be done for the class object.

Comment 4

[John Bandhauer]

How do ownership models fit in? Such things are not enforced. Any object exposed 
to the app is subject to having unanticipated (and perfectly legal) references. 
That is the nature of xpcom

What is this magic about class objects? What mechanism makes them "stay around 
for as long as all of its associated instances"? By one mechanism or another, in 
order to do safe dll unloading, accounting needs to be done for each and every 
object accessible by outside code. That is what I said at the start and I really 
can't figure out why you dispute it.

Comment 5

[Braden]

No magic; the refcounting mechanism ensures that they stay around as long as all
their instances. By definition, a class object holds data associated with all of
its instance objects, so it certainly shouldn't have a shorter lifetime than
they do. Instance objects can simply keep an owning reference to their class
object.

If all the instance objects have an owning reference to the class object, it
isn't going away before they do, regardless of who else AddRefs either the class
object or an instance object. And because of that, I don't see why it isn't
adequate to do accounting only on the class object.

Comment 6

[John Bandhauer]

You are simply talking about another mechanism for accounting for the lifetime 
of each and every object - not about no accounting at all. Having each object 
hold a reference on its class object has no less time overhead then the per dll 
counter I suggested. It does, however, add the space overhead of (at minimum) 
one additional pointer per object. If we opt to build generic systems to manage 
this accounting it would be better to minimize bloat. Reference counting via 
vtbl calls in a necessary evil for cross component interaction. But when it gets 
down to the internals of how a component interacts with its module we should be 
looking to make this tight and to minimize space/time cost.

Comment 7

[Ray Whitmer]

This will not happen soon.

Comment 8

[Warren Harris]

Assigning rest of xpcom stuff to myself (from Ray).

Comment 9

[Warren Harris]

Subject: 
             module unloading
  Resent-Date: 
             Thu, 19 Oct 2000 00:55:42 -0700 (PDT)
 Resent-From: 
             [e-mail]
        Date: 
             Thu, 19 Oct 2000 02:01:45 -0600
        From: 
             Bruce <[e-mail]>
          To: 
             [e-mail]




Good morning,

For whoever might have to work on module unloading on Linux, this
came over the glibc list today and may be relevant for them:

http://sources.redhat.com/ml/libc-alpha/2000-10/msg00226.html

Enjoy,

 - Bruce

Comment 10

[Christopher Blizzard (:blizzard)]

Just FYI, if Red Hat does another glibc update for Red Hat 7 the fix for this
problem will be in that update.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I filed bug 60709 to cover (some of?) what needs to be done to enable just the
code in nsDll::~nsDll that would cause dll unloading to happen at the end of
XPCOM shutdown (which is a tiny subset of what needs to be done for this bug, as
I read it).

Comment 12

[Asa Dotzler [:asa]]

reasigning warren bugs to default component owners.

Comment 13

[Doug Turner (:dougt)]

reassign all kandrot xpcom bug.

Comment 14

[Doug Turner (:dougt)]

*** This bug has been marked as a duplicate of 60709 ***