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

Pierre A. Humblet Pierre.Humblet@ieee.org
Sun Dec 7 02:22:00 GMT 2003

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 
- it seems possible to return from _threadinfo::remove () without having
  left the critical section.
- 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.
- a doubly linked list is not really needed.

Also FWIW, to avoid a critical section in find_tls, you could have the
sig_wait thread manage the tls list, adding and deleting the tls's. 
The threads that are willing to handle signals could sig_send a special
__SIGADDME signal (or __SIGREMME) and wait for an ack. You already have
the tls in the pack, so it looks very easy.
Of course that assumes that you have per thread events to ack the
sig_send, which seems to be your intention (from your FIXMENOW).


More information about the Cygwin-developers mailing list