This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Instability with signals and threads
- From: Mikulas Patocka <mikulas at artax dot karlin dot mff dot cuni dot cz>
- To: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- Cc: cygwin at cygwin dot com
- Date: Fri, 21 Nov 2014 15:11:14 +0100 (CET)
- Subject: Re: Instability with signals and threads
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1411202055420 dot 8559 at artax dot karlin dot mff dot cuni dot cz>
> 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 :(
Mikulas
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple