Mail Archives: cygwin/2011/08/26/07:16:20
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
- Raw text -