title: Is this a bug in glibc/pthread?
body: <p>I am using a robust mutex together with a condition. This works most of the time, but infrequently, I get deadlocks.
  I could not reduce this to a small, reproducible example, and I consider it very likely that it is a problem in my code, however, I noticed something that looks suspicious:</p>
  
  <p>When the code deadlocks, one thread is in pthread_cond_broadcast:</p>
  
  <pre><code>#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
  #1  0x00007f4ab2892970 in pthread_cond_broadcast@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_broadcast.S:133
  </code></pre>
  
  <p>Another thread is in pthread_mutex_lock, on the mutex which is used with the condition:</p>
  
  <pre><code>#0  __lll_robust_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevelrobustlock.S:85
  #1  0x00007f4ab288e7d7 in __pthread_mutex_lock_full (mutex=0x7f4a9858b128) at ../nptl/pthread_mutex_lock.c:256
  </code></pre>
  
  <p>As you can see, pthread_mutex_lock uses lowlevelrobustlock, while pthread_cond_broadcast uses lowlevellock. Is it possible that the condition somehow uses a non-robust mutex internally?</p>
  
  <p>I use the mutex to protected shared memory, and it is possible that one of the processes sharing it gets killed.
  So, maybe my deadlocks happen because the process was inside pthread_cond_broadcast when it was killed, and now, the other process can not broadcast, because the killed process still owns the mutex? After all, a similar situation was why I started using a robust mutex in the first place. </p>
  
  <p>PS: Situations where the process gets killed in the critical section are handled, the robust mutex works great. For all the deadlocks, I saw this situation where pthread_cond_broadcast was the active function. </p>
  
  <p>PPS: for the mutex, there is pthread_mutexattr_setrobust, but I could not find something like pthread_condattr_setrobust. Does it exist?</p>