Re: dtors run twice on dll detach (update)

[Christopher Faylor <cgf at redhat dot com>]

On Thu, May 02, 2002 at 03:37:24PM +0200, Benjamin Riefenstahl wrote:
>"Robert Collins" <robert.collins@itdomain.com.au> writes:
>> > If we just avoid setting up the destructor calls using atexit 
>> > then the destructors will only run once.  So, in the normal 
>> > case, the destructor will run after much cleanup has occurred 
>> > in the cygwin DLL (specifically in the do_exit function).  
>> > This means that the destructor may not be able to use all of 
>> > the facilities of cygwin when it is finally executed.
>> 
>> Yup. That is why I don't think that the atexit call is obsolete.
>>  
>> > This won't be an issue for the problem below, but I wonder if 
>> > it is a problem for other destructors.  I'm not sure what 
>> > kind of environment a global destructor is guaranteed to have 
>> > but I suspect that it should be a completely normal environment.
>> > 
>> > Anyone know for sure?  Is there an online reference for this 
>> > kind of thing?
>> 
>> It'll be in the C++ standard, which is proprietary :[. Anyone here have
>> the standard and care to check for us?
>
>C++ 98 in one spot (3.6.3 Termination, para 3) says that atexit()
>functions are called before destructors for objects created before
>registration of the atexit() functions and after destruction of
>objects created after registration.  IOW the order is as if destructor
>calls are implemented as atexit() functions.
>
>Later in the description of exit() (18.3 Start and Termination, para
>8) this is repeated.  Actions of exit() are defined to be in this
>order:
>
>- atexit() functions and destructor calls.
>
>- Flushing C streams. 
>
>- Return to OS with exit code. 
>
>Except for the addition of destructor calls, this is the same
>definition as in the C standard, judging from my copy of the last C9x
>draft.

I never thanked you for providing this information.  THANK YOU.

I finally got around to fixing this problem tonight.  I wanted to get
it into 1.3.11.

It should be in the next snapshot.

Although I didn't use the method in the patch, I do appreciate the amount
of work that went into tracking down the problem.  I think that my fix
will be a little less intrusive but it would have taken me very much
longer to figure out what was going on without the use of the patch.

Thanks,
cgf