This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread_attr_init() returning errors

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 []
Sent: Wednesday, April 20, 2016 7:40 AM
Cc: Canham, Timothy K (348C) <>
Subject: Re: pthread_attr_init() returning errors

On Apr 20 14:20, Canham, Timothy K (348C) wrote:
From: Corinna Vinschen []
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

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


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]