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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=gmIuzBc1qVCusNMg
	6qZCDz9mGsGjvKh53vmaRpAldow9pEFVFYaHQTieEK8hkCu/AMiSKHmBxnuUxfcu
	x7e0AjB/WpRaJcPFHuftuLh5NXuYbfY4K7GOBgFsbkOKxhDLS3tNm0AOzya9DTDL
	xL6kKwImisHcxQfSU4OBWzYGgRI=
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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=//w4Q9mpgZaT1oUAW2xn/g
	c6S24=; b=XB0ixPst7mxi2RD1soEcLqQlOMr6Aj5vyh80OZkJIWxxJiHb+ZEcsn
	yETkpvY7WK3jiEnIWKZHuWV1ESuJZXnlywWvRb52cqfCrGk/ltaDTcbsrVDX3/n8
	PsTBc3X5amlv8h5MiqyQutaue9RbhKPjtr5EGcVXu8DlFITB3qGes=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=Hx-languages-length:3793, highly, cygwin AT cygwin DOT com
X-HELO:	resqmta-po-12v.sys.comcast.net
Subject:	Re: pthread_attr_init() returning errors
To:	cygwin AT cygwin DOT com
References:	<E8EB3633A6A4594CA063A3FCBC82C18C3621F0F6 AT ap-embx-sp40 DOT RES DOT AD DOT JPL> <20160420105016 DOT GB26118 AT calimero DOT vinschen DOT de> <E8EB3633A6A4594CA063A3FCBC82C18C3621FDE3 AT ap-embx-sp40 DOT RES DOT AD DOT JPL> <20160420144013 DOT GC25668 AT calimero DOT vinschen DOT de> <E8EB3633A6A4594CA063A3FCBC82C18C3622039A AT ap-embx-sp40 DOT RES DOT AD DOT JPL>
From:	Ernie Rael <err AT raelity DOT com>
Message-ID:	<5717C800.4080009@raelity.com>
Date:	Wed, 20 Apr 2016 11:18:40 -0700
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version:	1.0
In-Reply-To:	<E8EB3633A6A4594CA063A3FCBC82C18C3622039A@ap-embx-sp40.RES.AD.JPL>
X-IsSubscribed:	yes

On 4/20/2016 10:22 AM, Canham, Timothy K (348C) wrote:
> I think I understand what happened now. The call to pthread_attr_init() is contained within a function we use to start threads. It is called successive times and it fails on the second call. It would appear that the stack entry gets laid out the exact same way as the previous call, so pthread_attr_init() sees the previous pthread_attr_t. I added a memset() of att and the issue went away. It looks like that is a good practice anyway.

Best practice might be using pthread_attr_destroy(attr).

>
> I would be interested in checking out the dev releases, but I don't want to mess with my working Cygwin install.
>
> Tim Canham
> JPL Flight Software
>
> -----Original Message-----
> From: Corinna Vinschen [mailto:corinna-cygwin AT cygwin DOT com]
> Sent: Wednesday, April 20, 2016 7:40 AM
> To: cygwin AT cygwin DOT com
> Cc: Canham, Timothy K (348C) <timothy DOT k DOT canham AT jpl DOT nasa DOT gov>
> Subject: Re: pthread_attr_init() returning errors
>
> On Apr 20 14:20, Canham, Timothy K (348C) wrote:
>>> From: Corinna Vinschen [mailto:corinna-cygwin AT cygwin DOT com]
>>> On Apr 19 19:49, Canham, Timothy K (348C) wrote:
>>>> I have some code to start a task that suddenly started failing.
>>>> This is pretty mature code. Here is the code fragment with my added
>>>> printf()
>>>>
>>>>          pthread_attr_t att;
>>>>          int stat = pthread_attr_init(&att);
>>>>          if (stat != 0) {
>>>>              printf("pthread_attr_init: (%d)(%d): %s\n",stat,errno,strerror(stat));
>>>>              // return
>>>>          }
>>>>
>>>> Here is the output:
>>>>
>>>> pthread_attr_init: (16)(0): Device or resource busy
>>> This is most unusual.  What happens is this:
>>>
>>> A pthread_attr_t is a pointer to a pointer to a struct with a magic
>>> number.  And at the start of pthread_attr_init this magic number is
>>> tested if it's already the magic number expected for an object of
>>> type pthread_attr_t.  And only if so, the pthread_attr_init function
>>> fails with EBUSY.
>>>
>>> That means, the arbitrary value in the uninitialized att prior to the
>>> call to pthread_attr_init is a pointer value which points to valid
>>> memory which has the magic value 0xdf0df048.  Wow.
>>>
>>> This means we can't keep up with the tests in the pthread_FOO_init
>>> functions since they could point to an *supposedly* initialized
>>> object, while in fact the value they point to is only accidentally so
>>> that it looks like an initialized object.
>>>
>>> I provided new developer snapshots on https://cygwin.com/snapshots/
>>> and I've just uploaded a 2.5.1-0.1 test release which you can install
>>> via setup as soon as your mirror has catched up.
>>>
>>> Pleaser give any of them a try.
>> So what you are saying is that when pthread_attr_init() checked for
>> the magic number in supposedly uninitialized memory it found the exact
>> value of the magic number? That seems highly suspect. Seems like it
>> may be pointing to a valid previous entry.
> That may be the case.  But in your example, pthread_attr_t att is very certainly uninitialized, being an uninitialized auto variable.  So, if it actually points to an already initialized pthread_addr_t, it does so by accident, because the stack slot it was previously used by another, initialized pthread_addr_t.  Therefore the check in pthread_attr_init is spurious.  Apparently there's a chance, albeit slim, that it returns EBUSY due to a false positive.
>
> POSIX says:
>
>    Results are undefined if pthread_attr_init() is called specifying an
>    already initialized attr attributes object.
>
> And neither is EBUSY defined as a valid return value, nor are such checks performed in glibc.  So I dropped the checks now in Cygwin as well.
>
> So, please give a dev snapshot or the 2.5.1-0.1 test release a try.
>
>
> Thanks,
> Corinna
>


--
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

- Raw text -