Mail Archives: cygwin-developers/2001/09/07/21:24:29
On Sat, Sep 08, 2001 at 12:47:53AM +0200, Corinna Vinschen wrote:
>On Fri, Sep 07, 2001 at 05:38:23PM -0400, Christopher Faylor wrote:
>> On Fri, Sep 07, 2001 at 07:09:51PM +0200, Corinna Vinschen wrote:
>> >>>Did this patch work? It seems to for me.
>> >>
>> >>The last we heard, another similar patch to this one didn't work for
>> >>Corinna.
>> >>
>> >>I'd like to get confirmation that this one works ok.
>> >
>> >Sorry, it doesn't work for me. I tried the plain version from CVS and
>> >the same including the cygheap.cc patch which you've send here. My
>> >testcase is a `make' in a Cygwin build tree. This testcase crashes now
>> >on a regular basis in /bin/sh. I'm getting the following backtrace in
>> >gdb with and without your yesterday's patch in cygheap.cc:
>>
>> The problem was, as I suspected, due to the zombies allocation. The
>> problem is that allocating the zombies array only when needed caused the
>> heap to grow while the program was in the process of forking. So,
>> when the parent tried to copy the heap to the child during a fork, the
>> heap was larger in the parent than in the child. Boom.
>
>When I read the above description I got a bit pale first... heap grows
>while program forks...
Yep. The process thread detects that a subprocess has ended and wants
to put the subprocess info in the zombie array. Meanwhile, our old
friend fork has started a child process and told it that the heap was x
bytes long. The subprocess thread grows the heap heap and the parent
tries to copy that much to it...
I am surprised that it was so easy to reproduce. It seems like it would
only happen when something was rapidly forking, but even then... It
makes me wonder if there is some unintentional synchronization going on
somewhere.
>> Corinna and Egor, can you verify if this checkin fixes things.
>
>That looks awful good now.
Phew. Thanks.
cgf
- Raw text -