I've put together a test case (see attached) which replicates what ruby is doing so that this problem can be repro'd without needing to build ruby. It seems that the failure only happens when the fork call is in a dll, and it also seems to depend on manipulating threads in close proximity to the fork.
Here's the test program under 1.7.7: $ uname -a CYGWIN_NT-6.1-WOW64 hkehoe1 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin $ ./testfork Before fork After fork pid=5060 After fork pid=0 subprocess status 0 (0x0) And here it is in the snapshot: $ uname -a CYGWIN_NT-6.1-WOW64 hkehoe1 1.7.8s(0.233/5/3) 20101102 14:03:08 i686 Cygwin $ ./testfork Before fork After fork pid=3808 subprocess status 32512 (0x7f00)Note the missing 'After fork' message from the child and the -127 exit status.
An strace of testfork will reveal this error occurring shortly after the fork returns in the child:
--- Process 2944, exception C0000005 at 610E4B8C (the process ID is the child's) ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System.For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
testfork.tgz
Description: Binary data
-- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple