Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: 6 Sep 2001 14:53:26 -0400
Message-ID: <20010906185326.20521.qmail@lizard.curl.com>
From: Jonathan Kamens <jik AT curl DOT com>
To: cygwin-developers AT cygwin DOT com
In-reply-to: <20010906184747.20476.qmail@lizard.curl.com> (message from
	Jonathan Kamens on 6 Sep 2001 14:47:47 -0400)
Subject: Re: Figured out how to reproduce vfork/rsync bug!
References: <20010906142836 DOT 7323 DOT qmail AT lizard DOT curl DOT com> <20010906164756 DOT 19885 DOT qmail AT lizard DOT curl DOT com> <20010906203947 DOT Q537 AT cygbert DOT vinschen DOT de> <20010906184747 DOT 20476 DOT qmail AT lizard DOT curl DOT com>

Ironically enough, the only significant thing checked in on July 17,
and thus the thing which caused this bug to start happening, is this:

  * child_info.h: Bump magic number.
  (class child_info): Add an element.
  * cygheap.cc (init_cheap): Allocate cygwin heap in shared memory area.
  (cygheap_fixup_in_child): Map cygwin heap, passed from parent via shared memory
  into correct address.
  (cygheap_setup_for_child): New function.
  * cygheap.h: Declare new functions.
  * dcrt0.cc (dll_crt0_1): Accomodate new cygheap_fixup_in_child arguments.
  Avoid protecting subproc_ready unless it is spawn/nowait.
  * fork.cc (fork_parent): Use new cygheap_setup_for_child function to setup
  cygwin heap info.  Close passed cygheap shared memory handle.
  * spawn.cc (spawn_guts): Ditto.  Also, reorganize to avoid synchronization
  between parent and child in non-P_OVERLAY case.
  * sigproc.cc (wait_sig): Only signal subproc_ready when execing.

Look familiar?

I think I'll try the patch that cgf just sent out and see if it makes
this problem go away.

It will be very amusing if we discover that the bug I'm encountering
is the same as Egor's.

  jik