pthread_attr_init() returning errors

[Ernie Rael]

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@cygwin.com]
> Sent: Wednesday, April 20, 2016 7:40 AM
> To: cygwin@cygwin.com
> Cc: Canham, Timothy K (348C) <timothy.k.canham@jpl.nasa.gov>
> Subject: Re: pthread_attr_init() returning errors
>
> On Apr 20 14:20, Canham, Timothy K (348C) wrote:
>>> From: Corinna Vinschen [mailto:corinna-cygwin@cygwin.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