Bug in fork() while in a thread

[Christopher Faylor]

On Sun, Aug 15, 2010 at 07:42:01PM +0200, Jason Curl wrote:
>Is it allowed to issue the fork() system call while not in the main 
>thread? When I read the OpenGroup specifications I don't seem to find 
>anything against allowing this.
>
>In particular, if I create a thread, then issue a fork(), data that 
>exists on the stack is corrupted after the fork() is in the child. Using 
>data on the heap doesn't show any issues (and is currently my 
>workaround, in case this is a bug).

If I'm reading this correctly then "the stack" in this case is the stack
associated with the main thread.  Cygwin only duplicates the stack in
the executing thread.  In your example, env (or presumably env2) from
the main thread is passed to another thread which then calls fork.  In
that scenario, the forked process is going to see garbage in env since
the array has never been initialized.

It is theoretically possible to duplicate the stack of the main thread
and other threads in the forked process but this isn't something that I,
personally, would want to take on.  I'm the guy who wrote the code that
duplicates the state of the stack when a thread forks.  It was done at
the request of a customer and it was very tricky to get right.  This
isn't an experience I'd willingly take on again since it would be a lot
of work, would require testing on every Windows OS from NT4 on, and
would potentially slow down an already slow down Cygwin's already slow
fork() implementation.

However, if this is something that you're willing to do, I'll happily
review a patch to the cygwin1.dll.  You'd need to modify fork related
code in dcrt0.cc.

cgf

--
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