Comment 15 for bug 1926265

> This is a valid issue, but are we certain it's the same one? The
> reporter talked about sched_yield and their backtraces included several
> threads of back_monitor waiting on some kind of lock.

You're right. It may be a different issue (though possibly linked to the same root cause). In my case, all other threads are stuck on:

#0 0x00007f2a010fdad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x55d92cadaa78) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x55d92cadaa28, cond=0x55d92cadaa50) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=cond@entry=0x55d92cadaa50, mutex=mutex@entry=0x55d92cadaa28) at pthread_cond_wait.c:655
#3 0x00007f2a01fc7475 in ldap_pvt_thread_cond_wait (cond=cond@entry=0x55d92cadaa50, mutex=mutex@entry=0x55d92cadaa28) at ../../../../libraries/libldap_r/thr_posix.c:277
#4 0x00007f2a01fc6d1b in ldap_int_thread_pool_wrapper (xpool=0x55d92cadaa20) at ../../../../libraries/libldap_r/tpool.c:683
#5 0x00007f2a010f76db in start_thread (arg=0x7f29f99b6700) at pthread_create.c:463
#6 0x00007f2a00e1971f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95