dtors run twice on dll detach (update)

Christopher Faylor cgf@redhat.com
Sat Jun 1 22:43:00 GMT 2002


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



More information about the Cygwin-patches mailing list