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

Assertion failure on lock_rec_queue_validate on multi-master load

    XMLWordPrintable

Details

    • Bug
    • Status: Stalled (View Workflow)
    • Critical
    • Resolution: Unresolved
    • 10.6
    • 10.6
    • Debug, Galera
    • None

    Description

      2024-04-18 16:08:07 0x73c7ec6856c0  InnoDB: Assertion failure in file /home/jan/work/mariadb/10.6/storage/innobase/lock/lock0lock.cc line 5248
      InnoDB: Failing assertion: lock->is_gap() || lock_rec_has_to_wait_in_queue(cell, lock)
      InnoDB: We intentionally generate a memory trap.
      InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
      InnoDB: If you get repeated assertion failures or crashes, even
      InnoDB: immediately after the mariadbd startup, there may be
      InnoDB: corruption in the InnoDB tablespace. Please refer to
      InnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/
      InnoDB: about forcing recovery.
      240418 16:08:07 [ERROR] mysqld got signal 6 ;
      Sorry, we probably made a mistake, and this is a bug.
       
      Your assistance in bug reporting will enable us to fix this for the next release.
      To report this bug, see https://mariadb.com/kb/en/reporting-bugs
       
      We will try our best to scrape up some info that will hopefully help
      diagnose the problem, but since we have already crashed, 
      something is definitely wrong and this may fail.
       
      Server version: 10.6.18-MariaDB-debug-log source revision: a1b6d9d02e37b64b32664a1443e65db28c69408b
      key_buffer_size=134217728
      read_buffer_size=131072
      max_used_connections=17
      max_threads=153
      thread_count=26
      It is possible that mysqld could use up to 
      key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 31489190 K  bytes of memory
      Hope that's ok; if not, decrease some variables in the equation.
       
      Thread pointer: 0x73c744000dc8
      Attempting backtrace. You can use the following information to find out
      where mysqld died. If you see no messages after this, something went
      terribly wrong...
      stack_bottom = 0x73c7ec684b38 thread_stack 0x49000
      mysys/stacktrace.c:215(my_print_stacktrace)[0x5905bf4f92f5]
      sql/signal_handler.cc:238(handle_fatal_signal)[0x5905beb935f9]
      libc_sigaction.c:0(__restore_rt)[0x73c830642990]
      nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x73c830699a1b]
      posix/raise.c:27(__GI_raise)[0x73c8306428e6]
      stdlib/abort.c:81(__GI_abort)[0x73c8306268b7]
      ut/ut0new.cc:84(ut_new_boot())[0x5905bf2b244f]
      lock/lock0lock.cc:5250(lock_rec_queue_validate(bool, page_id_t, unsigned char const*, dict_index_t const*, unsigned short const*))[0x5905bf0c829f]
      lock/lock0lock.cc:6096(lock_clust_rec_read_check_and_lock(unsigned long, buf_block_t const*, unsigned char const*, dict_index_t*, unsigned short const*, lock_mode, unsigned int, que_thr_t*))[0x5905bf0cbb34]
      row/row0sel.cc:1354(sel_set_rec_lock(btr_pcur_t*, unsigned char const*, dict_index_t*, unsigned short const*, unsigned int, unsigned int, que_thr_t*, mtr_t*))[0x5905bf21e2fb]
      row/row0sel.cc:5237(row_search_mvcc(unsigned char*, page_cur_mode_t, row_prebuilt_t*, unsigned long, unsigned long))[0x5905bf229bc2]
      handler/ha_innodb.cc:9334(ha_innobase::general_fetch(unsigned char*, unsigned int, unsigned int))[0x5905befff8ee]
      handler/ha_innodb.cc:9537(ha_innobase::rnd_next(unsigned char*))[0x5905befffe95]
      sql/handler.cc:3514(handler::ha_rnd_next(unsigned char*))[0x5905beb9fb63]
      sql/records.cc:519(rr_sequential(READ_RECORD*))[0x5905bed89ea1]
      sql/records.h:81(READ_RECORD::read_record())[0x5905be6fa0a9]
      sql/sql_select.cc:21899(sub_select(JOIN*, st_join_table*, bool))[0x5905be85086c]
      sql/sql_select.cc:21403(do_select(JOIN*, Procedure*))[0x5905be84fa67]
      sql/sql_select.cc:4884(JOIN::exec_inner())[0x5905be81ff69]
      sql/sql_select.cc:4663(JOIN::exec())[0x5905be81efa3]
      sql/sql_select.cc:5143(mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x5905be820980]
      sql/sql_select.cc:559(handle_select(THD*, LEX*, select_result*, unsigned long))[0x5905be80eb67]
      sql/sql_parse.cc:4783(mysql_execute_command(THD*, bool))[0x5905be7c4603]
      sql/sql_parse.cc:8146(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x5905be7cfcf1]
      sql/sql_parse.cc:7968(wsrep_mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x5905be7cf342]
      sql/sql_parse.cc:1883(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x5905be7bad6d]
      sql/sql_parse.cc:1409(do_command(THD*, bool))[0x5905be7b970e]
      sql/sql_connect.cc:1415(do_handle_one_connection(CONNECT*, bool))[0x5905be998591]
      sql/sql_connect.cc:1319(handle_one_connection)[0x5905be9982c6]
      perfschema/pfs.cc:2203(pfs_spawn_thread)[0x5905bef0ea0a]
      nptl/pthread_create.c:444(start_thread)[0x73c830697b5a]
      x86_64/clone3.S:80(clone3)[0x73c8307285fc]
       
      Trying to get some variables.
      Some pointers may be invalid and cause the dump to abort.
      Query (0x73c744014300): REPLACE INTO `table100_innodb_key_pk_parts_2_int` ( `col_int` ) SELECT `col_char_12_key` FROM `table10000_innodb_int_autoinc` AS X WHERE X.`col_int_key` BETWEEN 1 AND 7 /* QNO 913 CON_ID 35 */
       
      Connection ID (thread ID): 35
      Status: NOT_KILLED
      

      Attachments

        1. mariadb2.sh
          0.9 kB
        2. galera_stress.yy
          3 kB
        3. galera_stress.zz
          1 kB
        4. mysql.err
          4.52 MB
        5. mysql-1.err
          8.26 MB
        6. mysql-2.err
          4.30 MB

        Issue Links

          Activity

            People

              sysprg Julius Goryavsky
              janlindstrom Jan Lindström
              Votes:
              0 Vote for this issue
              Watchers:
              1 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.