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