sem_init() fails (when used in a certain way)

Corinna Vinschen
Tue Mar 29 15:53:00 GMT 2011

On Mar 29 14:41, Jon TURNEY wrote:
> $ ./sem_init_malloc_testcase
> sem_init: Device or resource busy
> [...]
> I'm not sure how to fix this:
> Changing sem_t from a pointer to an instance of class semaphore is not a good
> idea as it would change a lot of code, and a non-starter as it breaks ABI by
> changing sizeof(sem_t), and I have to assume there is a reason it was
> implemented using a pointer in the first place.
> Removing the is_good_object() check from semaphore::init() (and thus changing
> the undefined behaviour when a sem_init() is used twice from 'return EBUSY' to
> 'leak some memory') would work.  Perhaps downgrading the error to strace
> output "potential repeated semaphore initialization"?

This sounds like a good idea to me.  Given that the test can accidentally
identify the content of the semaphore as valid, the test is somewhat

> I hope someone has some better ideas?

I don't think there's any other way.  Glibc does not check the semaphore
storage at all when calling sem_init and SUSv4 states

  "Attempting to initialize an already initialized semaphore results in
   undefined behavior."

I'd say, just go ahead.


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

More information about the Cygwin-developers mailing list