pthread_attr_init() returning errors
Corinna Vinschen
corinna-cygwin@cygwin.com
Wed Apr 20 14:41:00 GMT 2016
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20160420/bb510b6b/attachment.sig>
More information about the Cygwin
mailing list