Details
-
Bug
-
Resolution: Fixed
-
P2: Important
-
4.8.5, 5.2.1
-
None
-
Mac OS X
Description
On unix, the system semaphore acquire/release is implemented calling semop with SEM_UNDO flag. If the semop fails a new semaphore is created and a new semop is performed on it and so on till there is a successful semop. On Mac OS there could be a crash due to an infinite recursive loop caused by a permanent failure in modifySemaphore() call.
This is happening because on Mac OS there is a limit set to 10 for the maximum number of SEM_UNDO structures a process can have initialized to a value different than 0 (just launch from command line 'sysctl kern.sysv.semume' to know that value). When more than 10 semaphores have the SEM_UNDO initialized, then the modifySemaphore will always fail causing the crash.
Attached is a simple example demonstrating the issue. A pool of producers threads are created. After acquire/release have been performed on more than 10 semaphores I get the crash on the mac.
Why the modifySemaphore, in the unix implementation, should create a new semaphore if the semop is failing?
Furthermore, I think calling the semop with the SEM_UNDO flag is basically wrong in the producer/consumer case, where a resource is always acquired by a process and released by another one (the SEM_UNDO counter for each process would be wrong, causing a bad semaphore value reset on process closure). The Qt API does not provide a way to acquire/release the semaphore without the SEM_UNDO flag.