This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: dtors run twice on dll detach (update)
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