|
In http://buildbot.askmonty.org/buildbot/builders/kvm-fulltest/builds/28094/steps/mtr_nm/logs/stdio we got a hang due to the following:
Thread 8 (Thread 0x7f2b93fff700 (LWP 28090)):
|
#0 0x00007f2bbc37c8e9 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
|
#1 0x000055df754bc3c4 in ssux_lock_low::writer_wait (l=<optimized out>, this=0x55df77c0f800) at /home/buildbot/buildbot/build/mariadb-10.6.0/storage/innobase/sync/srw_lock.cc:99
|
#2 ssux_lock_low::write_lock (this=0x55df77c0f800, holding_u=holding_u@entry=false) at /home/buildbot/buildbot/build/mariadb-10.6.0/storage/innobase/sync/srw_lock.cc:228
|
#3 0x000055df753ffb2f in ssux_lock_low::wr_lock (this=<optimized out>) at /home/buildbot/buildbot/build/mariadb-10.6.0/storage/innobase/include/srw_lock.h:97
|
#4 lock_sys_t::hash_latch::acquire (this=<optimized out>) at /home/buildbot/buildbot/build/mariadb-10.6.0/storage/innobase/include/lock0lock.h:606
|
This looks like a lost wakeup, and the cause ought to be the srw_mutex or srw_lock implementation. Unfortunately, the value of l is unavailable in the stack trace, but a code review strongly suggests that it cannot be UNLOCKED.
|