> 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
