Date: Thu, 24 May 2012 17:36:09 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.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@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <20120523085215.GG9200@calimero.vinschen.de> <20120523160625.GL9200@calimero.vinschen.de> <20120523171834.GM9200@calimero.vinschen.de> <4FBD217B.8000803@acm.org> <20120523175403.GN9200@calimero.vinschen.de> <20120523201041.GP9200@calimero.vinschen.de> <4FBE0730.6020103@sister-shadow.de> <4FBE0F0C.2020206@sister-shadow.de> <20120524111946.GB18736@calimero.vinschen.de> <4FBE4DCF.1060306@sister-shadow.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@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.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