X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=G+RzV NvayLK3hjamjDIby3fxBodUswtnvMCxVpb5TIPQVwj+2kf2cVOexTV4eHG7hEqk4 4i/kqsRPrjwsadwk1wRbnoi4JX8zLqE/mldA5BJi14WDqqsglt8YfDiJ4kzj9J0S 8xLckpquYmiyyaoQK/egObI2H2zZcZ+ELquDP0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=eVjuXmY4zOQ buPlPTjg2SJS1OGs=; b=CDlnalFYg0ixgGf4oxt6gtQ4ElzfElpy+vehQGVClgv TQAKnTc7ufQcKXN7EycygPfhCe6Kd4WjGE8FHuXKPgXQcBlb/+kCK0xMvhw6tKgR phwVUARbywQTpnaGNaG6+hVxuUWp6+MUrjhkmLoU+rhLkP1/C50rhhZujjsr7fds = Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Delivered-To: corinna-cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: artax.karlin.mff.cuni.cz Date: Fri, 21 Nov 2014 15:11:14 +0100 (CET) From: Mikulas Patocka To: Corinna Vinschen cc: cygwin AT cygwin DOT com Subject: Re: Instability with signals and threads In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) X-Personality-Disorder: Schizoid MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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