Instability with signals and threads

Mikulas Patocka
Fri Nov 21 14:46:00 GMT 2014

> Do you use a DLL built with optimization by any chance?  I wouldn't take 
> the backtraces too serious in that case.  For debugging it helps a lot 
> to use a Cygwin DLL built without -O2.

I use optimization. The stacktrace may contain some other functions that 
already finished but left the address on the stack.

> Btw., are you testing on 32 or 64 bit?

On 32-bit. The rebuild of cygwin1.dll requires large number of packages to 
create the documentation (including tex and java) and I haven't bloated 
the 64-bit cygwin installation with them yet. I wish it were possible to 
build the library without documentation and without such big dependecies.

> I'm testing on 64 bit. I can't reproduce your backtrace, but I can 
> reproduce another one, which is related to thread_exit.  At one point 
> after a couple thousand runs through your testcase I have a variable 
> number of threads hanging in thread_exit, and a timer thread which is 
> unable to send its signal.  the other threads all hang in thread_exit, 
> waiting for a muto which is taken by a thread which doesn't exist 
> anymore.

So you can - just for debugging - add a counter to thread local storage 
that is incremented when muto is taken and decremented when muto is 
released. If the thread exists, test the counter, if it is non-zero, print 
the backtrace or attach the debugger.

> That's a very serious downside of the muto implementation not 
> being able to recognize being abandoned. I wonder if that shouldn't be 
> using a real OS mutex.

That would hide the problem that a thread is exiting with locked muto, but 
not fix it.

> As a sidenote, the snapshot doesn't work well in 
> other scenarios, too, apparently.  Yaakov reported hangs in KDE :(


Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list