X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Fri, 26 Aug 2011 13:15:09 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: STC for libapr1 failure
Message-ID: <20110826111509.GH10490@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4E56EB24 DOT 5000505 AT acm DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4E56EB24.5000505@acm.org>
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 Aug 25 17:39, David Rothenberger wrote:
> For a while now, the test cases that come with libapr1 have been
> bombing with this message:
> 
>   *** fatal error - NtCreateEvent(lock): 0xC0000035
> 
> I finally took some time to investigate and have extracted a STC
> that demonstrates the problem.

Thanks a lot for the testcase.  In theory, the NtCreateEvent call should
not have happened at all, since it's called under lock, and the code
around that should have made sure that the object doesn't exist at the
time.

After a few hours of extrem puzzlement, I now finally know what happens.
It's kinda hard to explain.

A lock on a file is represented by an event object.  Process A holds the
lock corresponding with event a.  Process B tries to lock, but the lock
of process A blocks that.  So B now waits for event a, until it gets
signalled.  Now A unlocks, thus signalling event a and closing the handle
afterwards.  But A's time slice isn't up yet, so it tries again to lock
the file, before B returned from the wait for a.  And here a wrong
condition fails to recognize the situation.  It finds the event object,
but since it's recognized as "that's me", it doesn't treat the event as
a blocking factor.  This in turn is the allowance to create its own lock
event object.  However, the object still exists, since b has still an
open handle to it.  So creating the event fails, and rightfully so.

What I don't have is an idea how to fix this problem correctly.  I have
to think about that.  Stay tuned.


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