This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.26 deadlock with __resolv_conf_detach
- From: Douglas Jacobsen <dmjacobsen at lbl dot gov>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 19 Sep 2019 05:40:19 -0700
- Subject: Re: glibc 2.26 deadlock with __resolv_conf_detach
- References: <CAHaWJFFggk44GwPdQwiOY=cSDM_1QaWbZ8AVZpzuoX+19paFzA@mail.gmail.com> <mvmftksof9v.fsf@suse.de>
On Thu, Sep 19, 2019 at 1:34 AM Andreas Schwab <schwab@suse.de> wrote:
>
> On Sep 19 2019, Douglas Jacobsen <dmjacobsen@lbl.gov> wrote:
>
> > The scenario we've uncovered is that some vendor software runs a
> > multithreaded daemon, which then fork()s, and spawns a thread,
>
> In the forked child? If a multi-threaded process calls fork, the child
> may only call async-signal-safe functions.
>
Yes, the forked child is generating and joining a thread prior to
execve(), and then the child deadlocks. This code was not generating
problems in SLES12sp3 so it has the appearance of a new problem, but I
do understand what you're saying about async-signal-safe here. Would
the mechanism of failure here be that the lock variable in
glibc/resolv/resolv_conf.c is already locked in the parent process at
the time of fork() - or whenever the lookup is initially done from the
parent memory?
Thanks,
Doug