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 Tue, Mar 29, 2011 at 05:53:31PM +0200, Corinna Vinschen wrote:
>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.

I think we should put a

 myfault efault;
 if (efault.faulted ())

in place of the is_good_object() test and sprinkle those throughout the
other sem_* functions, if they're not already there.


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