[Bug 252579] fork() causes process to hang in rare circumstances.

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252579

Jason A. Harmening <jah at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jah at FreeBSD.org

--- Comment #1 from Jason A. Harmening <jah at FreeBSD.org> ---
I can reproduce this 100% of the time on a -current VM using the supplied test
code.   I noticed a few things:

--for me, the parent process seems to be hanging during fork(); I see no
evidence the child process is ever spawned.

--wmesg for the process is 'umtxn', and ddb shows what looks like the main
thread attempting to take a userspace lock, going through umtxq_lock(), and
sleeping in sleepq_wait_sig()

--I tried to write a smaller test program to reproduce the failure by
simulating the locking done by the NS dispatcher and the pthread_create()
issued by the stub, but this did not reproduce the hang.

--However, if I just link the original test program against libpthread ('cc -o
bug -pthread bug.c), then I can no longer reproduce the hang.   This tells me
the problem might have something to do with some bit of static umtx
initialization that happens when linking against libpthread/libthr.   If this
initialization hasn't happened by the time the NS dispatcher (which loads the
stub through dlopen()) is invoked, then fork() ends up stuck in a umtx wait
that never gets signaled.  It might also be related to the __isthreaded checks
made by lib/libc/net/nsdispatch.c, which smell fishy to me.

At the very least, it might be possible to make a smaller repro case by writing
a test program (that does not link libpthread) which dlopen()s a simple library
(which does link libpthread) and calls an entry point that spawns a thread.

-- 
You are receiving this mail because:
You are the assignee for the bug.