Instability with signals and threads
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
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: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin