[ruby-core:46433] [ruby-trunk - Bug #5811][Feedback] Ruby Process Deadlocks With Fork on Mac OS X Lion

Issue #5811 has been updated by mrkn (Kenta Murata).

Status changed from Assigned to Feedback

I need Gemfile to run your test.rb.
Please attach it.
----------------------------------------
Bug #5811: Ruby Process Deadlocks With Fork on Mac OS X Lion
https://bugs.ruby-lang.org/issues/5811#change-28053

Author: netshade (Chris Zelenak)
Status: Feedback
Priority: Normal
Assignee: mrkn (Kenta Murata)
Category: 
Target version: 
ruby -v: ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.2.0]


=begin
Given a Ruby process that acts like the following:

* Spawn new thread that initializes a TCPSocket
* Execute script using backticks in main thread

there is a chance that it will deadlock on Lion.  The GDB traces for the threads show:

* The TCP connecting thread stuck on native_cond_wait/thread_pthread.c:321 by way of rsock_getaddrinfo/raddrinfo.c:359
* The main thread stuck on read() by way of rb_f_backquote/io.c:7266

Meanwhile, in the forked process from rb_f_backquote: 

* The main thread is stuck at (longer trace):
 #0  0x00007fff9160c6b6 in semaphore_wait_trap ()
 #1  0x00007fff8fc03bc2 in _dispatch_thread_semaphore_wait ()
 #2  0x00007fff8fc04286 in dispatch_once_f ()
 #3  0x00007fff95e12f20 in si_module_static_search ()
 #4  0x00007fff95e16a3d in si_module_with_name ()
 #5  0x00007fff95e0eac8 in getpwuid ()
 #6  0x00007fff90daa842 in getgroups$DARWIN_EXTSN ()
 #7  0x000000010b82b020 in rb_group_member (gid=0) at file.c:1002
 #8  0x000000010b82b10f in eaccess (path=0x7fff6b3d3570 "/bin/hostname", mode=1) at file.c:1052
 ...

The documentation for getpwuid in Mac OS X Lion states that getpwuid now is threadsafe, much like getpwuid_r - however, the values returned by getpwuid are thread local and disposed automatically, as opposed to getpwuid_r's allocation of results.  The disassembly of semaphore_wait_trap and __psynch_cvwait  both show syscalls being made (I don't know how to go much further here), but the arguments are all void to these functions too when snooping in GDB.  I believe that the posix wait and semaphore_wait taking place are in fact making syscalls to wait on a condition variable of the same value - this value is the same due to the shared memory state of the fork.  

When an artificial delay ("sleep 1") is introduced after the creation of the TCP connect thread, this deadlock no longer occurs.

Attached is a test script that uses the Instrumental Agent gem for the TCP connect and can reliably cause the deadlock under 1.9.3.
=end



-- 
http://bugs.ruby-lang.org/