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

Assertion `thd->is_error() || kill_errno || thd->killed == ABORT_QUERY' failed in filesort

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Won't Fix
    • 10.1, 10.2
    • N/A
    • Partitioning, Server
    • None

    Description

      Setting it to Minor, as it only seems to affect debug builds of 10.1-10.2 (and probably earlier versions, but they are no longer supported), but not 10.3+.

      The test case is non-deterministic, run with repeat=N. It fails fairly well for me, usually within several attempts.

      --source include/have_sequence.inc
      --source include/have_partition.inc
      --source include/have_innodb.inc
       
      CREATE TABLE t1 (id INT AUTO_INCREMENT, a CHAR(15) DEFAULT '', b INT, t TIMESTAMP NOT NULL DEFAULT '1971-01-01 00:00:00', PRIMARY KEY(id,a), UNIQUE(b,id,a)) ENGINE=InnoDB PARTITION BY KEY(a) PARTITIONS 20;
      INSERT INTO t1 (a) SELECT '' FROM seq_1_to_50;
       
      --connect (con1,localhost,root,,test)
      START TRANSACTION;
      --send
        INSERT INTO t1 (a,b) SELECT '', seq FROM seq_1_to_100;
       
      --connection default
      SET innodb_lock_wait_timeout= 1;
      START TRANSACTION;
      --error ER_LOCK_WAIT_TIMEOUT,ER_FILSORT_ABORT
      DELETE FROM t1 WHERE id = 7 OR b != 6 ORDER BY b;
       
      # Cleanup
      --disconnect con1
      --connection default
      DROP TABLE t1;
      

      10.2 9dedba16

      mysqld: /data/src/10.2/sql/filesort.cc:385: SORT_INFO* filesort(THD*, TABLE*, Filesort*, Filesort_tracker*, JOIN*, table_map): Assertion `thd->is_error() || kill_errno || thd->killed == ABORT_QUERY' failed.
      200909 17:15:46 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f77fc841f36 in __GI___assert_fail (assertion=0x5609fab6ef50 "thd->is_error() || kill_errno || thd->killed == ABORT_QUERY", file=0x5609fab6ee18 "/data/src/10.2/sql/filesort.cc", line=385, function=0x5609fab6eeb0 "SORT_INFO* filesort(THD*, TABLE*, Filesort*, Filesort_tracker*, JOIN*, table_map)") at assert.c:101
      #8  0x00005609fa2176e3 in filesort (thd=0x7f77a0000d90, table=0x7f77a00c5a50, filesort=0x7f77f6ca6280, tracker=0x7f77a0014128, join=0x0, first_table_bit=0) at /data/src/10.2/sql/filesort.cc:385
      #9  0x00005609fa3b10cf in mysql_delete (thd=0x7f77a0000d90, table_list=0x7f77a0012808, conds=0x7f77a0013430, order_list=0x7f77a0005328, limit=18446744073709551615, options=0, result=0x0) at /data/src/10.2/sql/sql_delete.cc:503
      #10 0x00005609f9f9ee6c in mysql_execute_command (thd=0x7f77a0000d90) at /data/src/10.2/sql/sql_parse.cc:4362
      #11 0x00005609f9fa9a27 in mysql_parse (thd=0x7f77a0000d90, rawbuf=0x7f77a00126f8 "DELETE FROM t1 WHERE id = 7 OR b != 6 ORDER BY b", length=48, parser_state=0x7f77f6ca75f0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7733
      #12 0x00005609f9f97d36 in dispatch_command (command=COM_QUERY, thd=0x7f77a0000d90, packet=0x7f77a0008b51 "DELETE FROM t1 WHERE id = 7 OR b != 6 ORDER BY b", packet_length=48, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1823
      #13 0x00005609f9f96831 in do_command (thd=0x7f77a0000d90) at /data/src/10.2/sql/sql_parse.cc:1377
      #14 0x00005609fa0f0203 in do_handle_one_connection (connect=0x5609fcf9c660) at /data/src/10.2/sql/sql_connect.cc:1336
      #15 0x00005609fa0eff68 in handle_one_connection (arg=0x5609fcf9c660) at /data/src/10.2/sql/sql_connect.cc:1241
      #16 0x00005609fa91721e in pfs_spawn_thread (arg=0x5609fd4b3a40) at /data/src/10.2/storage/perfschema/pfs.cc:1869
      #17 0x00007f77fcd53609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #18 0x00007f77fc92d103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      Reproducible on 10.1-10.2. Couldn't reproduce on 10.3+.
      It is possible that the underlying problem was fixed (or masked!) at some point in 10.3+ by some other changes. It would explain why MDEV-18833, which was originally filed for 10.3+, doesn't seem to be reproducible anymore.

      The test case can be varied to make it fail on a SELECT instead (note extra setting for transaction isolation level):

      --source include/have_sequence.inc
      --source include/have_partition.inc
      --source include/have_innodb.inc
       
      CREATE TABLE t1 (id INT AUTO_INCREMENT, a CHAR(15) DEFAULT '', b INT, t TIMESTAMP NOT NULL DEFAULT '1971-01-01 00:00:00', PRIMARY KEY(id,a), UNIQUE(b,id,a)) ENGINE=InnoDB PARTITION BY KEY(a) PARTITIONS 20;
      INSERT INTO t1 (a) SELECT '' FROM seq_1_to_50;
       
      --connect (con1,localhost,root,,test)
      START TRANSACTION;
      --send
        INSERT INTO t1 (a,b) SELECT '', seq FROM seq_1_to_100;
       
      --connection default
      SET innodb_lock_wait_timeout= 1;
      SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
      START TRANSACTION;
      --error ER_LOCK_WAIT_TIMEOUT,ER_FILSORT_ABORT
      SELECT * FROM t1 WHERE id = 7 OR b != 6 ORDER BY b;
       
      # Cleanup
      --disconnect con1
      --connection default
      DROP TABLE t1;
      

      mysqld: /data/src/10.2/sql/filesort.cc:385: SORT_INFO* filesort(THD*, TABLE*, Filesort*, Filesort_tracker*, JOIN*, table_map): Assertion `thd->is_error() || kill_errno || thd->killed == ABORT_QUERY' failed.
      200909 21:32:25 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007fd3a0546f36 in __GI___assert_fail (assertion=0x55945acbdf50 "thd->is_error() || kill_errno || thd->killed == ABORT_QUERY", file=0x55945acbde18 "/data/src/10.2/sql/filesort.cc", line=385, function=0x55945acbdeb0 "SORT_INFO* filesort(THD*, TABLE*, Filesort*, Filesort_tracker*, JOIN*, table_map)") at assert.c:101
      #8  0x000055945a3666e3 in filesort (thd=0x7fd348000d90, table=0x7fd3480c5e10, filesort=0x7fd348016c40, tracker=0x7fd3480172d8, join=0x7fd348013898, first_table_bit=1) at /data/src/10.2/sql/filesort.cc:385
      #9  0x000055945a16423e in create_sort_index (thd=0x7fd348000d90, join=0x7fd348013898, tab=0x7fd348015db8, fsort=0x7fd348016c40) at /data/src/10.2/sql/sql_select.cc:22059
      #10 0x000055945a15e8bf in st_join_table::sort_table (this=0x7fd348015db8) at /data/src/10.2/sql/sql_select.cc:19821
      #11 0x000055945a15e50b in join_init_read_record (tab=0x7fd348015db8) at /data/src/10.2/sql/sql_select.cc:19762
      #12 0x000055945a15c450 in sub_select (join=0x7fd348013898, join_tab=0x7fd348015db8, end_of_records=false) at /data/src/10.2/sql/sql_select.cc:18853
      #13 0x000055945a15ba28 in do_select (join=0x7fd348013898, procedure=0x0) at /data/src/10.2/sql/sql_select.cc:18400
      #14 0x000055945a135685 in JOIN::exec_inner (this=0x7fd348013898) at /data/src/10.2/sql/sql_select.cc:3638
      #15 0x000055945a134b2c in JOIN::exec (this=0x7fd348013898) at /data/src/10.2/sql/sql_select.cc:3433
      #16 0x000055945a135cee in mysql_select (thd=0x7fd348000d90, tables=0x7fd348012920, wild_num=1, fields=..., conds=0x7fd348013558, og_num=1, order=0x7fd348013768, group=0x0, having=0x0, proc_param=0x0, select_options=2148797184, result=0x7fd348013878, unit=0x7fd348004988, select_lex=0x7fd3480050c8) at /data/src/10.2/sql/sql_select.cc:3833
      #17 0x000055945a129e94 in handle_select (thd=0x7fd348000d90, lex=0x7fd3480048c8, result=0x7fd348013878, setup_tables_done_option=0) at /data/src/10.2/sql/sql_select.cc:361
      #18 0x000055945a0f4c98 in execute_sqlcom_select (thd=0x7fd348000d90, all_tables=0x7fd348012920) at /data/src/10.2/sql/sql_parse.cc:6218
      #19 0x000055945a0eb55a in mysql_execute_command (thd=0x7fd348000d90) at /data/src/10.2/sql/sql_parse.cc:3524
      #20 0x000055945a0f8a27 in mysql_parse (thd=0x7fd348000d90, rawbuf=0x7fd3480126f8 "SELECT * FROM t1 WHERE id = 7 OR b != 6 ORDER BY b", length=50, parser_state=0x7fd39a9ac5f0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7733
      #21 0x000055945a0e6d36 in dispatch_command (command=COM_QUERY, thd=0x7fd348000d90, packet=0x7fd348008b51 "", packet_length=50, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1823
      #22 0x000055945a0e5831 in do_command (thd=0x7fd348000d90) at /data/src/10.2/sql/sql_parse.cc:1377
      #23 0x000055945a23f203 in do_handle_one_connection (connect=0x55945d98b660) at /data/src/10.2/sql/sql_connect.cc:1336
      #24 0x000055945a23ef68 in handle_one_connection (arg=0x55945d98b660) at /data/src/10.2/sql/sql_connect.cc:1241
      #25 0x000055945aa6621e in pfs_spawn_thread (arg=0x55945dea2a40) at /data/src/10.2/storage/perfschema/pfs.cc:1869
      #26 0x00007fd3a0a58609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #27 0x00007fd3a0632103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              1 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.