Re: deadlock in __new_exitfn

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Aug 30, 2005 at 12:17:45PM +0200, S?bastien Bouchex wrote:
> I have a problem of deadlock in the libc (2.3.2-95.33) on RH ES 3 Update 4.
>  
> #0  0x001fad19 in __lll_mutex_lock_wait () from /lib/tls/libc.so.6
> #1  0x0013b8a5 in _L_mutex_lock_73 () from /lib/tls/libc.so.6
> #2  0x0013b7c3 in __new_exitfn () from /lib/tls/libc.so.6
> #3  0x0013b784 in __cxa_atexit_internal () from /lib/tls/libc.so.6
> #4  0x0052f459 in malloc (sz=520) at usesimtls.cpp:39
> #5  0x0013b828 in __new_exitfn () from /lib/tls/libc.so.6
> #6  0x0013b784 in __cxa_atexit_internal () from /lib/tls/libc.so.6
> #7  0x07b62e3f in __static_initialization_and_destruction_0 ()
> #8  0x07b62e9a in global constructors keyed to err_sutl_packer_overflow ()
> #9  0x07b94cf5 in __do_global_ctors_aux ()
> #10 0x079e4176 in _init () from /usr/local/ODI/ostore/lib/libos.so
> #11 0x004f3b11 in _dl_init_internal () from /lib/ld-linux.so.2
> #12 0x004e7c95 in _dl_start_user () from /lib/ld-linux.so.2
> 
> At frame 4, the executed malloc is not the regular malloc but a derived one
> coming from libhoard (the fast allocator) that has been LD_PRELOAD'ed, the
> first thing done at frame 4 is the declaration of a static object and my
> test app hangs on the creation of this static.
> 
> But I'd like to understand why the creation of a static object implies a
> call to atexit ? I have check the glibc source code and did not find
> anything.

Because the static has to be destructed at exit time (or dlclose time).
You can choose if atexit or __cxa_atexit is called, see
info gcc --index-search="fuse-cxa-atexit"
The default is usually __cxa_atexit, as that will ensure proper behaviour
on dlclose.

	Jakub