[MDEV-25071] Assertion `!table->fts' failed in dict_make_room_in_cache from srv_master_evict_from_table_cache Created: 2021-03-06  Updated: 2021-03-09

Status: Open
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.6
Fix Version/s: 10.6

Type: Bug Priority: Major
Reporter: Roel Van de Paar Assignee: Roel Van de Paar
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File MDEV-25071.sql    

 Description   

I have been chasing this "complex to reproduce and reduce" bug for months. Let me list everything I have thus far. See this search for potentially related bugs.
1. I regularly see this crash (stack from test run sample, not from reduced testcase):

10.6.0 786bc312b85e58857cb26a24ab6e997ba0fdfc32

mysqld: /test/10.6_dbg/storage/innobase/dict/dict0dict.cc:1451: ulint dict_make_room_in_cache(ulint, ulint): Assertion `!table->fts' failed.

10.6.0 786bc312b85e58857cb26a24ab6e997ba0fdfc32

Core was generated by `/test/MD100221-mariadb-10.6.0-linux-x86_64-dbg/bin/mysqld --no-defaults --max_a'.
Program terminated with signal SIGABRT, Aborted.
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=6)
    at ../sysdeps/unix/sysv/linux/pthread_kill.c:56
[Current thread is 1 (Thread 0x14b548df6700 (LWP 4100654))]
(gdb) bt
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ../sysdeps/unix/sysv/linux/pthread_kill.c:56
#1  0x0000562d5f52d55e in my_write_core (sig=sig@entry=6) at /test/10.6_dbg/mysys/stacktrace.c:424
#2  0x0000562d5ecc54de in handle_fatal_signal (sig=6) at /test/10.6_dbg/sql/signal_handler.cc:330
#3  <signal handler called>
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#5  0x000014b57d893859 in __GI_abort () at abort.c:79
#6  0x000014b57d893729 in __assert_fail_base (fmt=0x14b57da29588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x562d5f9573b2 "!table->fts", file=0x562d5f9574b0 "/test/10.6_dbg/storage/innobase/dict/dict0dict.cc", line=1451, function=<optimized out>) at assert.c:92
#7  0x000014b57d8a4f36 in __GI___assert_fail (assertion=assertion@entry=0x562d5f9573b2 "!table->fts", file=file@entry=0x562d5f9574b0 "/test/10.6_dbg/storage/innobase/dict/dict0dict.cc", line=line@entry=1451, function=function@entry=0x562d5f9588e0 "ulint dict_make_room_in_cache(ulint, ulint)") at assert.c:101
#8  0x0000562d5f3e3d4a in dict_make_room_in_cache (max_tables=512, pct_check=pct_check@entry=100) at /test/10.6_dbg/storage/innobase/dict/dict0dict.cc:1451
#9  0x0000562d5f2b6b47 in srv_master_evict_from_table_cache (pct_check=pct_check@entry=100) at /test/10.6_dbg/storage/innobase/srv/srv0srv.cc:1496
#10 0x0000562d5f2b98d6 in srv_master_do_idle_tasks () at /test/10.6_dbg/storage/innobase/srv/srv0srv.cc:1690
#11 srv_master_callback () at /test/10.6_dbg/storage/innobase/srv/srv0srv.cc:1753
#12 0x0000562d5f4b9200 in tpool::thread_pool_generic::timer_generic::run (this=0x562d616870e0) at /test/10.6_dbg/tpool/tpool_generic.cc:309
#13 tpool::thread_pool_generic::timer_generic::execute (arg=0x562d616870e0) at /test/10.6_dbg/tpool/tpool_generic.cc:329
#14 0x0000562d5f4ba16b in tpool::task::execute (this=0x562d61687120) at /test/10.6_dbg/tpool/task.cc:52
#15 0x0000562d5f4b8d1b in tpool::thread_pool_generic::worker_main (this=0x562d60f08d60, thread_var=0x562d60f18400) at /test/10.6_dbg/tpool/tpool_generic.cc:546
#16 0x0000562d5f4b9052 in std::__invoke_impl<void, void (tpool::thread_pool_generic::*)(tpool::worker_data*), tpool::thread_pool_generic*, tpool::worker_data*> (__t=<optimized out>, __f=<optimized out>) at /usr/include/c++/9/bits/invoke.h:89
#17 std::__invoke<void (tpool::thread_pool_generic::*)(tpool::worker_data*), tpool::thread_pool_generic*, tpool::worker_data*> (__fn=<optimized out>) at /usr/include/c++/9/bits/invoke.h:95
#18 std::thread::_Invoker<std::tuple<void (tpool::thread_pool_generic::*)(tpool::worker_data*), tpool::thread_pool_generic*, tpool::worker_data*> >::_M_invoke<0ul, 1ul, 2ul> (this=<optimized out>) at /usr/include/c++/9/thread:244
#19 std::thread::_Invoker<std::tuple<void (tpool::thread_pool_generic::*)(tpool::worker_data*), tpool::thread_pool_generic*, tpool::worker_data*> >::operator() (this=<optimized out>) at /usr/include/c++/9/thread:251
#20 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (tpool::thread_pool_generic::*)(tpool::worker_data*), tpool::thread_pool_generic*, tpool::worker_data*> > >::_M_run (this=<optimized out>) at /usr/include/c++/9/thread:195
#21 0x000014b57dc85d84 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#22 0x000014b57dda1609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#23 0x000014b57d990293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

2. I have attached at testcase, which, when the following unreduced set of options:

--max_allowed_packet=33554432 --maximum-bulk_insert_buffer_size=1M --maximum-join_buffer_size=1M --maximum-max_heap_table_size=1M --maximum-max_join_size=1M --maximum-myisam_max_sort_file_size=1M --maximum-myisam_mmap_size=1M --maximum-myisam_sort_buffer_size=1M --maximum-optimizer_trace_max_mem_size=1M --maximum-preload_buffer_size=1M --maximum-query_alloc_block_size=1M --maximum-query_prealloc_size=1M --maximum-range_alloc_block_size=1M --maximum-read_buffer_size=1M --maximum-read_rnd_buffer_size=1M --maximum-sort_buffer_size=1M --maximum-tmp_table_size=1M --maximum-transaction_alloc_block_size=1M --maximum-transaction_prealloc_size=1M --log-output=none --sql_mode=ONLY_FULL_GROUP_BY --innodb_file_per_table=1 --innodb_flush_method=O_DIRECT --innodb_stats_persistent=off --loose-idle_write_transaction_timeout=0 --loose-idle_transaction_timeout=0 --loose-idle_readonly_transaction_timeout=0 --connect_timeout=60 --interactive_timeout=28800 --slave_net_timeout=60 --net_read_timeout=30 --net_write_timeout=60 --loose-table_lock_wait_timeout=50 --wait_timeout=28800 --lock-wait-timeout=86400 --innodb-lock-wait-timeout=50 --log_output=FILE --log-bin --log_bin_trust_function_creators=1 --loose-max-statement-time=30 --loose-debug_assert_on_not_freed_memory=0 --innodb-buffer-pool-size=300M

And using the pquery binary is able to reproduce (and previously reduce to this) the issue under reducer.sh, with the same uniqueID.
3. This bug closely relates to MDEV-25072 as I see a similar "closing tables" issue there, even though the testcase and setup is very different, with the exception of partitions being involved.

  • see that innnodb file close issue in log. in.sql running for this one.

Generated at Thu Feb 08 09:34:55 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.