In 10.5, the code was refactored by MDEV-22871, but I would not rule out this race condition. The hash table is being reallocated in buf_pool_t::resize_hash().
Marko Mäkelä
added a comment - In 10.5, the code was refactored by MDEV-22871 , but I would not rule out this race condition. The hash table is being reallocated in buf_pool_t::resize_hash() .
During the development of MDEV-22871, I translated a call hash_lock_x_all(buf_pool->page_hash) into a member function buf_pool_t::write_lock_all_page_hash(). I think that the motivation of that code was to prevent exactly this type of race condition. Apparently, the logic is flawed after all, or it needs to be revised.
Marko Mäkelä
added a comment - During the development of MDEV-22871 , I translated a call hash_lock_x_all(buf_pool->page_hash) into a member function buf_pool_t::write_lock_all_page_hash() . I think that the motivation of that code was to prevent exactly this type of race condition. Apparently, the logic is flawed after all, or it needs to be revised.
# 2020-10-26T19:43:16 [45476] | [rr 47250 529096]Shadow bytes around the buggy address:
# 2020-10-26T19:43:16 [45476] | 0x0c0e7fffd050: fd fd fd fd fd fa fa fa fa fa fd fd fd fd fd fd
# 2020-10-26T19:43:16 [45476] | 0x0c0e7fffd060: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fd
# 2020-10-26T19:43:16 [45476] | 0x0c0e7fffd070: fd fa fa fa fa fa fd fd fd fd fd fd fd fd fd fa
# 2020-10-26T19:43:16 [45476] | 0x0c0e7fffd080: fa fa fa fa fd fd fd fd fd fd fd fd fd fa fa fa
# 2020-10-26T19:43:16 [45476] | 0x0c0e7fffd090: fa fa fd fd fd fd fd fd fd fd fd fa fa fa fa fa
# 2020-10-26T19:43:16 [45476] | =>0x0c0e7fffd0a0: fd fd fd fd fd fd fd fd[fd]fa fa fa fa fa fd fd
# 2020-10-26T19:43:16 [45476] | 0x0c0e7fffd0b0: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd fd
# 2020-10-26T19:43:16 [45476] | 0x0c0e7fffd0c0: fd fd fd fd fd fa fa fa fa fa fd fd fd fd fd fd
# 2020-10-26T19:43:16 [45476] | 0x0c0e7fffd0d0: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fd
# 2020-10-26T19:43:16 [45476] | 0x0c0e7fffd0e0: fd fa fa fa fa fa fd fd fd fd fd fd fd fd fd fa
# 2020-10-26T19:43:16 [45476] | 0x0c0e7fffd0f0: fa fa fa fa fd fd fd fd fd fd fd fd fd fa fa fa
(rr) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00004e4c1c474859 in __GI_abort () at abort.c:79
#2 0x00006d506e64b6a2 in ?? () from /lib/x86_64-linux-gnu/libasan.so.5
#3 0x00006d506e65624c in ?? () from /lib/x86_64-linux-gnu/libasan.so.5
#4 0x00006d506e6378ec in ?? () from /lib/x86_64-linux-gnu/libasan.so.5
#5 0x00006d506e637363 in ?? () from /lib/x86_64-linux-gnu/libasan.so.5
#6 0x00006d506e6381ab in __asan_report_load8 () from /lib/x86_64-linux-gnu/libasan.so.5
#7 0x000055abdfa30999 in hash_get_nth_lock (i=6, table=0x607000028500) at /home/mleich/Server/bb-10.3-MDEV-23693A/storage/innobase/include/hash0hash.ic:196
#8 hash_get_lock (table=0x607000028500, fold=833) at /home/mleich/Server/bb-10.3-MDEV-23693A/storage/innobase/include/hash0hash.ic:222
#9 0x000055abdfa61318 in buf_page_hash_lock_get (page_id=..., buf_pool=0x61b000001580) at /home/mleich/Server/bb-10.3-MDEV-23693A/storage/innobase/include/buf0types.h:167
line=161, mtr=0x64000046e320, err=0x0) at /home/mleich/Server/bb-10.3-MDEV-23693A/storage/innobase/buf/buf0buf.cc:4927
#12 0x000055abdf87aa22 in trx_undo_page_get_s_latched (mtr=0x64000046e320, page_id=...) at /home/mleich/Server/bb-10.3-MDEV-23693A/storage/innobase/include/trx0undo.ic:161
#13 trx_purge_get_next_rec (n_pages_handled=n_pages_handled@entry=0x64000046e960, heap=heap@entry=0x613000002880) at /home/mleich/Server/bb-10.3-MDEV-23693A/storage/innobase/trx/trx0purge.cc:1316
#14 0x000055abdf87b8b8 in trx_purge_fetch_next_rec (roll_ptr=roll_ptr@entry=0x613000002910, n_pages_handled=n_pages_handled@entry=0x64000046e960, heap=0x613000002880) at /home/mleich/Server/bb-10.3-MDEV-23693A/storage/innobase/trx/trx0purge.cc:1382
#15 0x000055abdf87c455 in trx_purge_attach_undo_recs (n_purge_threads=n_purge_threads@entry=4) at /home/mleich/Server/bb-10.3-MDEV-23693A/storage/innobase/trx/trx0purge.cc:1456
#16 0x000055abdf881f98 in trx_purge (n_purge_threads=4, truncate=<optimized out>, slot=slot@entry=0x55abe14dc348 <srv_sys+328>) at /home/mleich/Server/bb-10.3-MDEV-23693A/storage/innobase/trx/trx0purge.cc:1592
#17 0x000055abdf7e5535 in srv_do_purge (n_total_purged=n_total_purged@entry=0x64000046ec40, slot=slot@entry=0x55abe14dc348 <srv_sys+328>) at /home/mleich/Server/bb-10.3-MDEV-23693A/storage/innobase/srv/srv0srv.cc:2637
#18 0x000055abdf7ec09f in srv_purge_coordinator_thread (arg=<optimized out>) at /home/mleich/Server/bb-10.3-MDEV-23693A/storage/innobase/srv/srv0srv.cc:2769
#19 0x00001468b4fe0609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#20 0x00004e4c1c571103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
We fix the race condition by never resizing (and reallocating) the buf_pool.page_hash. We assume that resizing the buffer pool is a rare operation. Yes, there might be a performance regression if a server is first started up with a tiny buffer pool, which is later enlarged.
Porting that fix to earlier releases would involve some nontrivial effort, because before MDEV-15058 the buffer pool was split into multiple instances.
Marko Mäkelä
added a comment - I think that this has been fixed by MDEV-26033 in MariaDB 10.5.12 and 10.6.3.
We fix the race condition by never resizing (and reallocating) the buf_pool.page_hash . We assume that resizing the buffer pool is a rare operation. Yes, there might be a performance regression if a server is first started up with a tiny buffer pool, which is later enlarged.
Porting that fix to earlier releases would involve some nontrivial effort, because before MDEV-15058 the buffer pool was split into multiple instances.
This was fixed by MDEV-26033 in the MariaDB Server 10.5 release series. I don’t think we should spend time on fixing this in earlier major versions.
Marko Mäkelä
added a comment - This was fixed by MDEV-26033 in the MariaDB Server 10.5 release series. I don’t think we should spend time on fixing this in earlier major versions.
In 10.5, the code was refactored by
MDEV-22871, but I would not rule out this race condition. The hash table is being reallocated in buf_pool_t::resize_hash().