Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-25071

Assertion `!table->fts' failed in dict_make_room_in_cache from srv_master_evict_from_table_cache

    XMLWordPrintable

    Details

      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.

        Attachments

          Activity

            People

            Assignee:
            Roel Roel Van de Paar
            Reporter:
            Roel Roel Van de Paar
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:

                Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.