[FreeBSD 5.3-RC2] Processes STILL hanging in unkillable state

Julian Elischer julian at elischer.org
Thu Nov 4 14:35:07 PST 2004



Dan Nelson wrote:

>In the last episode (Nov 04), Marc Ramirez said:
>  
>
>>On Thursday 04 November 2004 09:36 am, Mike Makonnen wrote:
>>    
>>
>>>Hmm, looks like the application is using libthr and not libpthread.
>>>I'll take a look at it, but in the mean time you might want to map
>>>libthr and libc_r to libpthread in libmap.conf(5).
>>>
>>>Can all other users with this problem verify which threading
>>>library they're running? You can use the following command on the
>>>binary. For example: # ldd /path/to/binary
>>>      
>>>
>>Not me.  Thanks!
>>    
>>
>
>I just noticed this on my machine as well (SMP, 5.3-stable as of
>yesterday), running a testsuite program linked to libpthreads.  It
>creates 10 threads whose only job is to fork(), exec /bin/sleep, kill
>-9 the child, and wait for the status.  Each thread does this 1000
>times in a tight loop.  Occasionally the whole thing will end up
>STOPped, but resumes within 60 seconds.  If I ktrace the process during
>this, I see a long delay followed by:
>
> 39117 pike     RET   fork 0
> 32592 pike     RET   fork 39117/0x98cd
>
>Could there be a race or deadlock within the kernel's fork() routines?
>What happens if two threads on different CPUs decide to fork at the
>same time?
>

fork is supposed to go into "single threading" mode, where only the 
thread that is running fork() is running,
until it completes.
All other threads are temporarily "suspended" until the thread finishes 
the fork, and it will not proceed into the fork()
until it has confirmed that they ARE suspended.

David Xu just fixed a small bug in this however, so get latest 
kern_thread.c (1.205) and try again.

this code is common to libthr and libpthread.


>
>  
>



More information about the freebsd-current mailing list