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

Assertion `thd->killed != 0' failed in ha_maria::enable_indexes

Details

    Description

      MTR test case (it's non-deterministic, run with --mem --repeat=N. For me, N=10 was always enough for all of 10.1-10.4, but it can vary on different machines and builds.

      CREATE TABLE t1 (a INT, b CHAR(12), c INT, FULLTEXT KEY(b), KEY (c)) ENGINE=Aria;
      CREATE TABLE t2 (a INT, b CHAR(12), c INT) ENGINE=Aria;
       
      INSERT INTO t2 VALUES (1,'foo',8), (2,'bar',9);
       
      --connect (con1,localhost,root,,test)
      --send
        INSERT INTO t1 SELECT * FROM t2;
       
      --connection default
      SHOW WARNINGS;
      --error ER_NO_SUCH_TABLE
      DELETE FROM non_existing_table;
      --error ER_NO_SUCH_TABLE
      SELECT * FROM t1 WHERE a = ( SELECT 1 FROM non_existing_table2 );
       
      --connection con1
      --reap
       
      # Cleanup
      --disconnect con1
      --connection default
      DROP TABLE t1, t2;
      

      10.1 b87b8c1344

      2018-08-25  4:13:20 140662472878848 [Warning] Warning: Enabling keys got errno 137 on test.t1, retrying
      mysqld: /data/src/10.1/storage/maria/ha_maria.cc:2023: virtual int ha_maria::enable_indexes(uint): Assertion `thd->killed != 0' failed.
      180825  4:13:20 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007fee86b6fee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      #8  0x000055b0f54e68c9 in ha_maria::enable_indexes (this=0x7fee7e032088, mode=2) at /data/src/10.1/storage/maria/ha_maria.cc:2023
      #9  0x000055b0f54e6f94 in ha_maria::end_bulk_insert (this=0x7fee7e032088) at /data/src/10.1/storage/maria/ha_maria.cc:2217
      #10 0x000055b0f50c6aef in handler::ha_end_bulk_insert (this=0x7fee7e032088) at /data/src/10.1/sql/handler.h:2854
      #11 0x000055b0f50c4152 in select_insert::prepare_eof (this=0x7fee7e0a7f38) at /data/src/10.1/sql/sql_insert.cc:3772
      #12 0x000055b0f50c4778 in select_insert::send_eof (this=0x7fee7e0a7f38) at /data/src/10.1/sql/sql_insert.cc:3865
      #13 0x000055b0f5148824 in do_select (join=0x7fee7e0a7fd8, fields=0x7fee7f8ed3d0, table=0x0, procedure=0x0) at /data/src/10.1/sql/sql_select.cc:18171
      #14 0x000055b0f5122ea8 in JOIN::exec_inner (this=0x7fee7e0a7fd8) at /data/src/10.1/sql/sql_select.cc:3275
      #15 0x000055b0f5120139 in JOIN::exec (this=0x7fee7e0a7fd8) at /data/src/10.1/sql/sql_select.cc:2562
      #16 0x000055b0f51236cf in mysql_select (thd=0x7fee7f8e9070, rref_pointer_array=0x7fee7f8ed560, tables=0x7fee7e0a78a8, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3489925888, result=0x7fee7e0a7f38, unit=0x7fee7f8ecbb8, select_lex=0x7fee7f8ed2b8) at /data/src/10.1/sql/sql_select.cc:3499
      #17 0x000055b0f5118d88 in handle_select (thd=0x7fee7f8e9070, lex=0x7fee7f8ecaf0, result=0x7fee7e0a7f38, setup_tables_done_option=1073741824) at /data/src/10.1/sql/sql_select.cc:388
      #18 0x000055b0f50e1cc1 in mysql_execute_command (thd=0x7fee7f8e9070) at /data/src/10.1/sql/sql_parse.cc:4039
      #19 0x000055b0f50ec368 in mysql_parse (thd=0x7fee7f8e9070, rawbuf=0x7fee7e0a7088 "INSERT INTO t1 SELECT * FROM t2", length=31, parser_state=0x7fee88ba95e0) at /data/src/10.1/sql/sql_parse.cc:7463
      #20 0x000055b0f50dacfd in dispatch_command (command=COM_QUERY, thd=0x7fee7f8e9070, packet=0x7fee7f8ef071 "INSERT INTO t1 SELECT * FROM t2", packet_length=31) at /data/src/10.1/sql/sql_parse.cc:1495
      #21 0x000055b0f50d9a82 in do_command (thd=0x7fee7f8e9070) at /data/src/10.1/sql/sql_parse.cc:1124
      #22 0x000055b0f5213ecd in do_handle_one_connection (thd_arg=0x7fee7f8e9070) at /data/src/10.1/sql/sql_connect.cc:1330
      #23 0x000055b0f5213c31 in handle_one_connection (arg=0x7fee7f8e9070) at /data/src/10.1/sql/sql_connect.cc:1242
      #24 0x000055b0f55d2024 in pfs_spawn_thread (arg=0x7fee860399f0) at /data/src/10.1/storage/perfschema/pfs.cc:1861
      #25 0x00007fee88873494 in start_thread (arg=0x7fee88baab00) at pthread_create.c:333
      #26 0x00007fee86c2c93f in clone () from /lib/x86_64-linux-gnu/libc.so.6
      

      Attachments

        Activity

          Problem was that a parallel open of a table, overwrote info->state that
          was in used by repair.

          This was basically a bug that only affected DEBUG running index rebuilds as the failed
          fast repair would be retried (which should always succeed) and for next operation on the
          table, the local status would be automatically corrected.

          Fixed by changing _ma_tmp_disable_logging_for_table() to use
          a new state buffer state.no_logging to store the temporary state.

          monty Michael Widenius added a comment - Problem was that a parallel open of a table, overwrote info->state that was in used by repair. This was basically a bug that only affected DEBUG running index rebuilds as the failed fast repair would be retried (which should always succeed) and for next operation on the table, the local status would be automatically corrected. Fixed by changing _ma_tmp_disable_logging_for_table() to use a new state buffer state.no_logging to store the temporary state.

          People

            monty Michael Widenius
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

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