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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat