X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Thu, 24 May 2012 17:36:09 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: 1.7.15-1: pthread_cancel and pthread_kill not working as expected Message-ID: <20120524153609.GA4225@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20120523085215 DOT GG9200 AT calimero DOT vinschen DOT de> <20120523160625 DOT GL9200 AT calimero DOT vinschen DOT de> <20120523171834 DOT GM9200 AT calimero DOT vinschen DOT de> <4FBD217B DOT 8000803 AT acm DOT org> <20120523175403 DOT GN9200 AT calimero DOT vinschen DOT de> <20120523201041 DOT GP9200 AT calimero DOT vinschen DOT de> <4FBE0730 DOT 6020103 AT sister-shadow DOT de> <4FBE0F0C DOT 2020206 AT sister-shadow DOT de> <20120524111946 DOT GB18736 AT calimero DOT vinschen DOT de> <4FBE4DCF DOT 1060306 AT sister-shadow DOT de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4FBE4DCF.1060306@sister-shadow.de> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 On May 24 17:03, Otto Meta wrote: > On 2012-05-24 13:19, Corinna Vinschen wrote: > > You know that Cygwin is just a user space DLL, right? There's no state > > information kept in the OS beyond the lifetime of any process using the > > Cygwin DLL. In case of pthreads, there's no state at all shared with > > other processes. > > Yes, that’s exactly why I’m confused about it. > > > But even if so, if you stop *all* Cygwin processes and then start > > another one, all info from the old processes is gone and you should be > > back to normal. If that's not the case, I would suspect a case of BLODA. > > Yes, I tried that and it changed nothing. I took the chance to uninstall > some unused software and stopped all dodgy-sounding Windows services, > including Windows Defender, so that the only thing left from the BLODA > was the nVidia driver: No change. > > Rebasing also didn’t help. > > >> If the test code includes semaphore.h but doesn’t even use any of its > >> functions it fails right away, just like before. A reboot doesn’t help. > > Is that with the same "read" testcases you sent two days ago? If so, I > > can't reproduce it. I ran both tests in a loop, with and without an > > additional semaphore.h, but to no avail. They both just work. > > Yes, same tests (the ones blocking on read()), but the semaphore.h was > probably unrelated after all. > > I also ran the tests continuously and discovered the following: > > Running the same test several times manually from a cmd shell works a > few times, then fails. Running the async and deferred tests alternating > from cmd works, even after they failed previously. > > Running one of the tests manually from bash fails most of the time. Weird. I tried under CMD now as well, but it still runs and runs and runs, without a failure. Tested on XP, W7, and 2008 R2. Another idea is that your system also fails due to the problem reported in http://cygwin.com/ml/cygwin/2012-05/msg00522.html I'm just about to generate another snapshot. You could see if that helps for some reason. I doubt it, but still... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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