Bug#884776: libc6: pthread_cond_broadcast() blocks indefinitely on process-shared cond-var
On Wed, Dec 27, 2017 at 09:22:50AM +0100, Aurelien Jarno wrote:
> Debian should make sure this change doesn't break any software we ship
> in the archive.
today i've checked all 19217 reverse-depend-packages of libc6 in
"testing" whether they use ROBUST-marked pthread-mutexes together with a
pthread-condvar in their source. (the fact that they decided to use a
ROBUST mutex could indicate that they expect lock-holders to die
without cleanup and they might not be aware that the condvar is not
ROBUST).
of the ~14 hits only two of them could probably break due to the new
condvar:
package firebird3.0 (version 3.0.2.32703.ds4-12)
this sql server makes use of the pshared mutex & condvar combination
in their src/common/isc_sync.cpp which provides shm-based services for
their LockManager, EventManager and MappingIpc classes.
i don't know whether or not it is to be expected in their use-case that
lock-holders might disappear or get killed (oom killer is always there
looking for memory hungry server processes) (they provide different
server models, among others also a multi-process model...)
the only other thing i found is
boost1.63-1.63.0+dfsg and boost1.62-1.62.0+dfsg.
i tried to build the package and the only code-section that seems to
be active (on amd64) and uses pshared condvars is:
libs/log/src/posix/ipc_sync_wrappers.hpp:
class boost::log::ipc::aux::interprocess_condition_variable
now the next job would be to check whether any debian packages uses
those classes expecting a robust condvar...
maybe on another day...
Reply to: