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


> 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.

What document exactly was this quote from?

In the standard, the relevant text is in 3.6.3 [basic.term], and reads

>> 1 Destructors (12.4) for initialized objects of static storage
>> duration (declared at block scope or at namespace scope) are called
>> as a result of returning from main and as a result of calling exit
>> (18.3). These objects are destroyed in the reverse order of the
>> completion of their constructor or of the completion of their
>> dynamic initialization.

Please note that we are talking about static objects at block scope.
It goes on with atexit interleaving

>> 3 If a function is registered with atexit (see <cstdlib>, 18.3)
>> then following the call to exit, any objects with static storage
>> duration initialized prior to the registration of that function
>> shall not be destroyed until the registered function is called from
>> the termination process and has completed. For an object with
>> static storage duration constructed after a function is registered
>> with atexit, then following the call to exit, the registered
>> function is not called until the execution of the object's
>> destructor has completed. If atexit is called during the
>> construction of an object, the complete object to which it belongs
>> shall be destroyed before the registered function is called.

> The standard doesn't address shared libraries at all (by making
> destruction pending to atexit()).

No, the standard talks about 'programs', and clearly means the
executable and all libraries linked with it. If you mean it doesn't
address interworking with dlopen(3) and dlclose(3) - you're right.

> Note that is doesn't specify the order of destruction within the
> function scope or the compilation unit scope.

Maybe your text doesn't - the C++ standard certainly does. For file
scope, you get destruction in reverse definition order, since you
are guarenteed construction in definition order.

> 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.

Which is wrong. Please note that shared libraries are *primarily* used
for that - sharing library code; not for dynamic loading. It is
currently an implementation restriction of g++ that you can't have
block-local static variables in an object loaded with dlopen.

> The enclosed example demonstrates a situation that you consider wrong
> but I consider right.

Maybe you don't want a compiler that conforms to the ISO standard. I
do.  Destructor order *is* irrelevant if the destructors don't have
side effects. The destructors in your example do have side effects.

> 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.

There is no point in fixing some programs, and breaking others.
I have a patch at

http://www.cygnus.com/ml/egcs-patches/1998-Sep/0371.html

It gives you the option of
a) doing it conformant to C++ (using atexit for everything), or
b) not using atexit at all (with some loss of C++ semantics), or
c) doing both a), and still supporting dlclose

Unfortunately, option c) requires an extension to the C library, which
didn't get integrated into glibc so far.

Regards,
Martin


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