[Bug dynamic-link/19329] dl-tls.c assert failure at concurrent pthread_create and dlopen

["nsz at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19329

--- Comment #38 from Szabolcs Nagy <nsz at gcc dot gnu.org> ---
(In reply to xujing from comment #35)
> (In reply to cvs-commit@gcc.gnu.org from comment #31)
> > commit 1387ad6225c2222f027790e3f460e31aa5dd2c54
> > Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
> > Date:   Wed Dec 30 19:19:37 2020 +0000
> > 
> >     elf: Fix data races in pthread_create and TLS access [BZ #19329]
> >     
> this patch use dl_load_lock in _dl_allocate_tls_init, is there a problem
> when dlopen a dynamic library which will call pthread_create? I think it
> will cause dl_load_lock and dl_load_lock dead lock.

the real bug is that ctors are run with the dlopen lock held.
that can causes deadlocks anyway (a ctor can create threads
and that thread can call dlopen). this is bug 15686 which is not
easy to fix, but that's the right solution. (in general, running
user callbacks while libc internal locks are held is wrong.)

that bug is now more exposed because the lock is also taken
at _dl_allocate_tls_init during thread creation. however i
expect that to be called in the parent thread only, so there
should be no deadlock when ctor calls pthread_create, only
when the child thread calls it again (which i considered rare).

if you have example code that you think should work but now
deadlocks, then please report it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.