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: Fri, 7 Sep 2001 11:31:34 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Figured out how to reproduce vfork/rsync bug! (proposed fix)
Message-ID: <20010907113134.A26741@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
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> <20010906185326 DOT 20521 DOT qmail AT lizard DOT curl DOT com> <20010906161343 DOT A4873 AT redhat DOT com> <20010906210458 DOT A8242 AT redhat DOT com> <20010907131921 DOT C17245 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20010907131921.C17245@cygbert.vinschen.de>
User-Agent: Mutt/1.3.21i

On Fri, Sep 07, 2001 at 01:19:21PM +0200, Corinna Vinschen wrote:
>On Thu, Sep 06, 2001 at 09:04:58PM -0400, Christopher Faylor wrote:
>> On Thu, Sep 06, 2001 at 04:13:43PM -0400, Christopher Faylor wrote:
>> >On Thu, Sep 06, 2001 at 02:53:26PM -0400, Jonathan Kamens wrote:
>> >>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.
>> >
>> >Try this.
>> 
>> I think this is the actual fix.  I noticed this about four hours ago but
>> concluded that there just HAD to be something wrong with the cygheap
>> stuff since that is what I had previously been working on.
>> 
>> I believe that cygheap was not the problem in this case.  What is actually
>> happening is that the it is assumed prot_info_ptr is a zero filled array --
>> that is not the case when you set that long environment variable.  The
>> environment variable space was freed and then reused by the cmalloc
>> in fhandler_socket::fhandler_socket.  So, when you look at the buffer
>> it actually contains the contents of the environment variable.  That is
>> acceptable behavior for cmalloc, of course but it looks like the
>> subsequent code in fhandler_socket.cc needs assumes that this buffer
>> is zeroed.
>> 
>> Anyway, I checked in the fix below.  It seems to resolve the problems.
>> On further investigation, my previous fix was bogus.  It just resulted
>> in never freeing space for the cygwin environment, which is incorrect.
>> 
>> Jonathan, Corinna, could you try the CVS version of cygwin and see
>> if it fixes the problem?
>
>It seems to fix it.  I'm mildly surprised, though.  prot_info_ptr is
>used twice, first in `fixup_before_fork_exec' where it's getting
>it's content and then in `fixup_after_fork' where it's content is
>used to create the new socket handle.
>
>If it's actually _used_ before being _set_ that would mean,
>`fixup_after_fork' has been called w/o calling `fixup_before_fork_exec'
>first.  But that would be simply wrong.
>
>So the only other explanation would be that `WSADuplicateSocketA'
>needs a zero filled buffer on input?!?

Apparently.  Your analysis is why I didn't pursue the zero-filled
solution for a long time.  It just didn't seem like it was necessary
to do this.

However, after laboriously walking through cygwin's startup code in
fork/exec situations, I finally convinced myself that the cygheap stuff
was actually working.  So, the only difference between working and
non-working that I could see was that prot_info_ptr was filled with
zeroes in the working case.

Anyway, I hope that this is a real fix and not a bandaid.

cgf