This is the mail archive of the cygwin-developers 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: sem_init() fails (when used in a certain way)


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

> 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

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


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