Bug#816742: libc6: sem_post/sem_wait not working for 32bit to 64bit inter-process communication
control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=17980
On 2016-03-04 09:45, Markus Friedrich wrote:
> Package: libc6
> Version: 2.21
> Severity: critical
> Justification: breaks unrelated software
>
> Inter-process communication between a 64bit and a 32bit process is not
> working. At least pthread named semaphores are not working.
> A sem_wait is not awaken if a corresponding sem_post is done on the other
> side, which generated a dead lock.
>
> This problem only exists if a 64bit process communicates with a 32bit
> process but not for 32bit to 32bit communication or 64bit to 64bit
> communication.
This has been caused by a rewrite of the semaphore code:
| commit 042e1521c794a945edc43b5bfa7e69ad70420524
| Author: Carlos O'Donell <carlos@systemhalted.org>
| Date: Wed Jan 21 00:46:16 2015 -0500
|
| Fix semaphore destruction (bug 12674).
|
| This commit fixes semaphore destruction by either using 64b atomic
| operations (where available), or by using two separate fields when only
| 32b atomic operations are available. In the latter case, we keep a
| conservative estimate of whether there are any waiting threads in one
| bit of the field that counts the number of available tokens, thus
| allowing sem_post to atomically both add a token and determine whether
| it needs to call futex_wake.
|
| See:
| https://sourceware.org/ml/libc-alpha/2014-12/msg00155.html
For the full commit, see:
https://sourceware.org/git/?p=glibc.git;a=commit;h=042e1521c794a945edc43b5bfa7e69ad70420524
It corresponds to upstream bug BZ 17980:
https://sourceware.org/bugzilla/show_bug.cgi?id=17980
> Moreover Debian 8.3 and all other tested distributions have no problem with
> 64bit to 32bit inter-process communication using pthread named semaphores.
Given the issue is due to an upstream commit and not to a Debian
specific change, all distributions with a glibc >= 2.21 are affected.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: