Re: Bug in fork() while in a thread

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Mon, Aug 16, 2010 at 11:05:52AM +0200, Corinna Vinschen wrote:
>On Aug 15 14:53, Christopher Faylor wrote:
>> 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 [...]
>
>I guess I'm missing something here.  Here's an excerpt from the SUSv4
>fork man page:
>
>  The fork() function shall create a new process. The new process (child
>  process) shall be an exact copy of the calling process (parent process)
>  except as detailed below:
>
>  [...]
>
>  o A process shall be created with a single thread. If a
>    multi-threaded process calls fork(), the new process shall contain
>    a replica of the calling thread and its entire address space,
>    possibly including the states of mutexes and other resources.
>    [...]
>
>Is the stack of another thread, which is not executed in the forked
>process anymore, a part of the calling's thread "entire address space"?

I saw that too but I can confirm that linux duplicates the main thread.
That isn't too surprising since it probably just replicates the entire
address space of the process including all of the stacks of all of the
threads.

Cygwin is more "efficient" than that.

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