fix cond_race... was RE: src/winsup/cygwin ChangeLog thread.h ...

Robert Collins
Sat Sep 29 21:58:00 GMT 2001

----- Original Message -----
From: "Norman Vine" <>
To: "'Robert Collins'" <>; "'Jason
Tishler'" <>
Cc: <>
Sent: Sunday, September 30, 2001 1:39 AM
Subject: RE: fix cond_race... was RE: src/winsup/cygwin ChangeLog thread.h ...

> Robert Collins writes:
> >----- Original Message -----
> >From: "Jason Tishler" <>
> >>
> >> On Fri, Sep 28, 2001 at 05:48:16PM +1000, Robert Collins wrote:
> >> > Well this patch should make evreything good -  fixing the
> >> > section induced race.
> >>
> >> At the risk of appearing dense...  Should this patch fix the
> hang
> >> trigger by Python's test_threadedtempfile regression test?
> >
> >I've checked in my completed code. I -cannot- tickle this bug via my
> >test suite at all now. (I found that one of my test scripts was
> >buggy in that it made an incorrect assumption - it was passing when
> >bug was tickled - correcting that let me hit this bug nearly every
> >:]).
> >
> >So please, give it a go and see how it fares.
> This now causes a hard crash in any of the Python threading tests
> with an attempt to read memory at 0x00000018 failure.
> Note I believe this started, for me at least, with the second piece of
> patch.
> Also note that I could not tickle this bug before.

Interesting. Well I can drop you an updated test case which I'm sure
will tickle the older .dll. Also I found that backgrounding the window
the test is running in took the chance of hitting the bug from "very
likely" to "sure thing" - if you'll excuse the technical talk :].

> Win2k sp2  Cygwin=ntsec   python src 2-1.1-2 from cygwin distribution
> gdb does attach to the failed python process
> Is there any further info I can send.

Yes. I don't have python build environment, nor much interest in having
one - so you'll need to find what bit of cygwin code is dying, and then
I'll come up with a fix for you.

> Being a bit of a gdb tweeb I may need fairly detailed instructions
> as to the gdb commands to issue

Start with bt, to get a back trace. From there look to see which
function has died. If for example the crash occured in
__pthread_cond_signal, then you would do a info locals to get local
data, and send me the bt and the info local output.

If the crash occured somewhere more detailed, like check_null_address,
then going up a frame or two would help. Lastly, if there is a class
method and a pthread wrapper both in the stack frame, info locals from
both is very useful. In the class method be sure to include the output
p *this
as well.


More information about the Cygwin-patches mailing list