Bug in fork() while in a thread
Mon Aug 16 09:06:00 GMT 2010
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"?
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin