Re: glibc 2.26 deadlock with __resolv_conf_detach

[Douglas Jacobsen <dmjacobsen@lbl.gov>]

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