X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Mon, 14 Feb 2011 10:20:54 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Preremove/postinstall scripts fail with snapshot installed
Message-ID: <20110214092054.GB14998@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4D55A88E DOT 3090301 AT cornell DOT edu> <20110212142555 DOT GB5682 AT calimero DOT vinschen DOT de> <4D56A002 DOT 2090707 AT cornell DOT edu> <4D56A7D5 DOT 6010104 AT cornell DOT edu> <20110212164415 DOT GB3264 AT calimero DOT vinschen DOT de> <20110212181224 DOT GC3264 AT calimero DOT vinschen DOT de> <20110213162449 DOT GA20855 AT calimero DOT vinschen DOT de> <4D5812DD DOT 8030600 AT cornell DOT edu> <4D58643A DOT 4040400 AT cornell DOT edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4D58643A.4040400@cornell.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Feb 13 18:07, Ken Brown wrote:
> On 2/13/2011 12:20 PM, Ken Brown wrote:
> >Works for me on W7 64 bit with KB 2393802 installed.
> 
> BTW, when I said that it works, I was talking about the original bug
> that I reported about preremove/postinstall scripts.  But I just now
> tested removing an in-use directory, and I was surprised by what
> happened.  Maybe I just don't understand how this is supposed to
> work. I have two bash shells open, with prompts $1 and $2.
> 
> In shell 1:
> 
> $1 mkdir /tmp/foo
> $1 cd /tmp/foo
> 
> In shell 2:
> 
> $2 rmdir /tmp/foo
> $2 ls /tmp/foo
> ls: cannot access /tmp/foo: No such file or directory
> 
> Back to shell 1:
> 
> $1 ls
>       0 [main] bash 2220 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION

Yes, I encountered that at one point yesterday as well, and I have
already a patch in the pipe, but didn't apply it so far because I
want to do some tests first.

What happens is this.

When Cygwin forks, it actually performs some magic centered around
a call to CreateProcess.  Up to Windows 2003, the CreateProcess
call just duplicates the parent's CWD handle and stores it as the
CWD handle in the child.  Starting with Windows Vista, the CWD handle
is always a fresh one, created on process startup, even if the CWD
of the child is the same as the CWD of the parent.

The problem with this scenario is that in the child process the CWD
handle creation fails, because the requested CWD doesn't exist anymore.
The result is that an important pointer in the OS is NULL.  My change
from yesterday neglected this possibility, so it dereferences this 
pointer without checking it for NULL, which in turn crashes.

Unfortunately it's not just adding a simple test, because Cygwin needs
the pointer to figure out which version of the FAST_CWD structure is
used.

Anyway, I'll apply a patch later today.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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