[f]statvfs (was Re: bug in statfs)

Christopher Faylor cgf@redhat.com
Sun Dec 7 02:48:00 GMT 2003


On Sat, Dec 06, 2003 at 09:21:38PM -0500, Pierre A. Humblet wrote:
>At 12:16 PM 12/6/2003 -0500, Christopher Faylor wrote:
>>On Sat, Dec 06, 2003 at 12:01:00PM -0500, Pierre A. Humblet wrote:
>>>Actually I am making some progress.  As noted before all I get is a pop
>>>up about a fault in cygwin1.dll After trying numerous times in gdb, I
>>>captured something useful.  Apparently the problem happens during
>>>DLL_THREAD_DETACH when few threads are still alive.  A threadinfo
>>>linked list appears to be screwed up.  Now let me reboot...
>>
>>This particular problem should have been fixed in CVS around 5:29 GMT.
>>It was pretty easy to duplicate using the technique I'd previously
>>advocated of debugging a bash which was running a script that was
>>known to fail -- at least on WinXP/2003.  I don't know why WinME
>>would be any different in this regard.
>
>That's the technique I used, it just takes some patience.
>
>I had rebuilt at around 3:00 GMT on 12/6 and I had you 12/5 ChangeLog
>entry, thus that change was already included.
>The critical section you added this afternoon seems to help a lot.
>
>I had a look at the code and noticed a few things that may or may not 
>matter:
>- it seems possible to return from _threadinfo::remove () without having
>  left the critical section.

Fixed, but this obviously was not the cause of the reported problem
especially since in the current code this should be an extremely
unlikely (if not impossible) occurrence.

>- shouldn't the critical section be used in find_tls()? It's going
>  to misbehave if a list element is deleted while it walks the list.

I'll change that.  Again, this is an unlikely, if not impossible,
occurrence in bash, though.

So, are you saying the problem is gone now?  I don't know how the
critical section would have solved this since it wasn't even intended
for that purpose.

cgf



More information about the Cygwin-developers mailing list