This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

glibc 2.26 deadlock with __resolv_conf_detach


We've found a possible deadlock in glibc 2.26 that is shipped with
SLES 15.  The scenario we've uncovered is that some vendor software
runs a multithreaded daemon, which then fork()s, and spawns a thread,
then waits for that thread to terminate (pthread_join()), and finally
takes action like execve()ing.

The specific stack trace we see in the deadlock is:

Thread 2 (Thread 0x2aaacca09700 (LWP 140473)):
#0  0x00002aaaac483b9c in __lll_lock_wait_private () from /lib64/
#1  0x00002aaaac498148 in get_locked_global () from /lib64/
#2  0x00002aaaac499139 in __resolv_conf_detach () from /lib64/
#3  0x00002aaaac4e4aba in res_thread_freeres () from /lib64/
#4  0x00002aaaac4e4a62 in __libc_thread_freeres () from /lib64/
#5  0x00002aaaac16758e in start_thread () from /lib64/
#6  0x00002aaaac476a2f in clone () from /lib64/

The other thread is just waiting on this one to join.  I'm fairly
unclear as to why the static "lock" variable in resolv_conf.c is
deadlocking here, unless there is some connection to that earlier
fork(), or there is some other mechanism I do not understand (which is
very possible).

In any case, it looks like sometime after glibc 2.26 was released, a
further update (124e0258) was made to this code to explicitly order
how these freeres functions were called.  Was this done to address
this kind of deadlock scenario or for a different reason?

commit 124e025864bb39732c71fc60c1443d5680881a0a
Author: Florian Weimer <>
Date:   Tue Jun 26 15:13:54 2018 +0200

    Run thread shutdown functions in an explicit order

    This removes the __libc_thread_subfreeres hook in favor of explict

    Reviewed-by: Carlos O'Donell <>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]