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