Richard Kettlewell  writes:
>scott_at_slp53.sl.home (Scott Lurndal) writes:
>> Joshua Maurice  writes:
>
>>>Let's suppose I have an application written on Linux using pthreads in
>>>C++ using the standard approaches. What can one make of the following
>>> stack trace?
>>>
>>>#0  0x00002af777d06abd in pthread_cond_destroy_at__at_GLIBC_2.3.2 () from /
>>>lib64/libpthread.so.0
>>>#1  0x00002af7b12aed22 in
>>>XxxConditionVariable::~XxxConditionVariable() () from xxx.so
>>>#2  0x00002af77825c2ed in exit () from /lib64/libc.so.6
>>
>>>From the stack trace, I guess that there is a global or static object
>>>of type XxxConditionVariable, and that g++ implements the calling of
>>>the global's destructor with a function registered with atexit.
>>
>> Static constructors are not called by atexit(), but rather they are
>> part of the .fini section which becomes a vector of static class
>> instances whose destructors need to be called when 'exit(2)' is
>> invoked, and are called by the glibc exit(2) function; much the same
>> way that the _start function in the crt calls the static constructors
>> before calling main.
>
>I think you mean to say that static destrucotrs are not registere with
>atexit().  In effect, though, they are; the destructors are registered
>by calling __cxa_atexit() for each object just after its construction,
>and atexit() is just a one-line wrapper around __cxa_atexit().
>
>(True at least on x86 with GCC 4.3-4.6.)

yes, that's what I meant to say.

s