This is the mail archive of the libc-hacker@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bug with dlclose and static class elements


"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:

> > Pretty straightforward patch.
> 
> And pretty wrong as well. Destructors must be run in inverse order of
> construction. I doubt your patch has this property (egcs 1.1 doesn't
> have this property, either - at least not in all cases - but your
> patch makes it worse).

>From an old C++ (pre-standard):
Section r6.7: Declaration Statement:
   The destructor for a local static object will be executed if and
   only if the variable was constructed. The destructor must be called
   either immediately before or as part of the calls of the atexit()
   functios (cf 3.4). Exactly when is undefined.

The standard doesn't address shared libraries at all (by making
destruction pending to atexit()).
Note that is doesn't specify the order of destruction within the
function scope or the compilation unit scope.

The old situation (registering destructors with atexit) causes a jump
to unmapped memory if the library has been closed before calling
exit(). But it had the property of calling the destructor in the exact
inverse order of construction in the program scope.

With my patch, destructors are called when a shared library is closed
and when the program terminates with exit(). The destruction only
happens if the variable has been constructed and in the reverse order
of appearance in the compilation unit.

The enclosed example demonstrates a situation that you consider wrong
but I consider right. The main opens and close the theared library
four times:
 1) Once only constructing 'always', does the right thing.
 2) Constructing 'always' and 'a1', ok.
 3) Constructing 'always', 'a1' and 'a2', destruction is the reverse
    order of construction.
 4) Constructing 'always', 'a2' and 'a1', destruction happens in this
    order: 'a2', 'a1' and finally 'always'.

I'd argue that in the case 4, destruction order is irrelevant (even
though the standard doesn't address this issue) because you cannot use
'a2' in 'a1' wihtout having some problems.

I do believe that this patch implements a better way of handling
statics when shared libraries are involved. With the current
implementation of egcs, dlclose() can wreak havoc.

Phil.

shlib.cpp

main.cpp


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]