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

Assertion `! thd->in_sub_stmt' failed in trans_commit_stmt / SEQUENCE::read_initial_values

Details

    Description

      10.3 e8b6c150

      mysqld: /data/src/10.3/sql/transaction.cc:512: bool trans_commit_stmt(THD*): Assertion `! thd->in_sub_stmt' failed.
      190214 20:36:32 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f625c45aee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      #8  0x000056471166dd7b in trans_commit_stmt (thd=0x7f6208000b00) at /data/src/10.3/sql/transaction.cc:512
      #9  0x00005647116fdd38 in SEQUENCE::read_initial_values (this=0x7f62080b9a08, table=0x7f62080bc380) at /data/src/10.3/sql/sql_sequence.cc:493
      #10 0x0000564711f68aba in ha_sequence::open (this=0x7f62080bdbd8, name=0x7f620806c3b0 "./test/s1", mode=2, flags=18) at /data/src/10.3/sql/ha_sequence.cc:114
      #11 0x00005647117f6989 in handler::ha_open (this=0x7f62080bdbd8, table_arg=0x7f62080bc380, name=0x7f620806c3b0 "./test/s1", mode=2, test_if_locked=18, mem_root=0x0, partitions_to_open=0x0) at /data/src/10.3/sql/handler.cc:2733
      #12 0x000056471160c128 in open_table_from_share (thd=0x7f6208000b00, share=0x7f620806be68, alias=0x7f62080ab890, db_stat=33, prgflag=8, ha_open_flags=18, outparam=0x7f62080bc380, is_create_table=false, partitions_to_open=0x0) at /data/src/10.3/sql/table.cc:3495
      #13 0x0000564711467157 in open_table (thd=0x7f6208000b00, table_list=0x7f62080ab848, ot_ctx=0x7f625579b480) at /data/src/10.3/sql/sql_base.cc:1975
      #14 0x000056471146a1a4 in open_and_process_table (thd=0x7f6208000b00, lex=0x7f625579b760, tables=0x7f62080ab848, counter=0x7f625579b54c, flags=1346, prelocking_strategy=0x7f625579b550, has_prelocking_list=false, ot_ctx=0x7f625579b480) at /data/src/10.3/sql/sql_base.cc:3596
      #15 0x000056471146b3a0 in open_tables (thd=0x7f6208000b00, options=..., start=0x7f625579b530, counter=0x7f625579b54c, flags=1346, prelocking_strategy=0x7f625579b550) at /data/src/10.3/sql/sql_base.cc:4121
      #16 0x00005647114634e2 in open_tables (thd=0x7f6208000b00, tables=0x7f625579b530, counter=0x7f625579b54c, flags=1346, prelocking_strategy=0x7f625579b550) at /data/src/10.3/sql/sql_base.h:250
      #17 0x000056471146d342 in open_normal_and_derived_tables (thd=0x7f6208000b00, tables=0x7f62080ab848, flags=1346, dt_phases=35) at /data/src/10.3/sql/sql_base.cc:5059
      #18 0x000056471146d51b in open_tables_only_view_structure (thd=0x7f6208000b00, table_list=0x7f62080ab848, can_deadlock=true) at /data/src/10.3/sql/sql_base.cc:5116
      #19 0x0000564711598e0f in fill_schema_table_by_open (thd=0x7f6208000b00, mem_root=0x7f625579cfd0, is_show_fields_or_keys=false, table=0x7f620804dd68, schema_table=0x564712a69b80 <schema_tables+1216>, orig_db_name=0x7f6208064938, orig_table_name=0x7f6208064998, open_tables_state_backup=0x7f625579d020, can_deadlock=true) at /data/src/10.3/sql/sql_show.cc:4566
      #20 0x000056471159a73f in get_all_tables (thd=0x7f6208000b00, tables=0x7f620803acc8, cond=0x0) at /data/src/10.3/sql/sql_show.cc:5204
      #21 0x00005647115ab7a8 in get_schema_tables_result (join=0x7f62080626c8, executed_place=PROCESSED_BY_JOIN_EXEC) at /data/src/10.3/sql/sql_show.cc:8802
      #22 0x0000564711544668 in JOIN::exec_inner (this=0x7f62080626c8) at /data/src/10.3/sql/sql_select.cc:4003
      #23 0x0000564711543cee in JOIN::exec (this=0x7f62080626c8) at /data/src/10.3/sql/sql_select.cc:3834
      #24 0x0000564711544f8e in mysql_select (thd=0x7f6208000b00, tables=0x7f620803acc8, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=4026534656, result=0x7f620804db30, unit=0x7f620803bab0, select_lex=0x7f620803c220) at /data/src/10.3/sql/sql_select.cc:4239
      #25 0x0000564711536eb4 in handle_select (thd=0x7f6208000b00, lex=0x7f620803b9e8, result=0x7f620804db30, setup_tables_done_option=1073741824) at /data/src/10.3/sql/sql_select.cc:385
      #26 0x00005647114fb2a8 in mysql_execute_command (thd=0x7f6208000b00) at /data/src/10.3/sql/sql_parse.cc:4837
      #27 0x000056471142356e in sp_instr_stmt::exec_core (this=0x7f620803b320, thd=0x7f6208000b00, nextp=0x7f625579eb64) at /data/src/10.3/sql/sp_head.cc:3594
      #28 0x00005647114229cb in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f620803b368, thd=0x7f6208000b00, nextp=0x7f625579eb64, open_tables=false, instr=0x7f620803b320) at /data/src/10.3/sql/sp_head.cc:3322
      #29 0x0000564711423150 in sp_instr_stmt::execute (this=0x7f620803b320, thd=0x7f6208000b00, nextp=0x7f625579eb64) at /data/src/10.3/sql/sp_head.cc:3500
      #30 0x000056471141cecb in sp_head::execute (this=0x7f6208039648, thd=0x7f6208000b00, merge_da_on_success=false) at /data/src/10.3/sql/sp_head.cc:1354
      #31 0x000056471141e04d in sp_head::execute_trigger (this=0x7f6208039648, thd=0x7f6208000b00, db_name=0x7f6208075108, table_name=0x7f6208075118, grant_info=0x7f6208039290) at /data/src/10.3/sql/sp_head.cc:1763
      #32 0x00005647115e43cc in Table_triggers_list::process_triggers (this=0x7f620800e338, thd=0x7f6208000b00, event=TRG_EVENT_INSERT, time_type=TRG_ACTION_BEFORE, old_row_is_record1=true) at /data/src/10.3/sql/sql_trigger.cc:2212
      #33 0x00005647114763d0 in fill_record_n_invoke_before_triggers (thd=0x7f6208000b00, table=0x7f62080a6f30, ptr=0x7f6208006a30, values=..., ignore_errors=false, event=TRG_EVENT_INSERT) at /data/src/10.3/sql/sql_base.cc:8623
      #34 0x00005647114b8dcc in mysql_insert (thd=0x7f6208000b00, table_list=0x7f6208014dc8, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false) at /data/src/10.3/sql/sql_insert.cc:1006
      #35 0x00005647114fab3a in mysql_execute_command (thd=0x7f6208000b00) at /data/src/10.3/sql/sql_parse.cc:4730
      #36 0x00005647115058a5 in mysql_parse (thd=0x7f6208000b00, rawbuf=0x7f6208014ce8 "INSERT INTO t1 VALUES (1)", length=25, parser_state=0x7f62557a05f0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8095
      #37 0x00005647114f2a59 in dispatch_command (command=COM_QUERY, thd=0x7f6208000b00, packet=0x7f6208168451 "INSERT INTO t1 VALUES (1)", packet_length=25, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1854
      #38 0x00005647114f1431 in do_command (thd=0x7f6208000b00) at /data/src/10.3/sql/sql_parse.cc:1396
      #39 0x000056471165974f in do_handle_one_connection (connect=0x564713b3b7b0) at /data/src/10.3/sql/sql_connect.cc:1403
      #40 0x00005647116594d3 in handle_one_connection (arg=0x564713b3b7b0) at /data/src/10.3/sql/sql_connect.cc:1309
      #41 0x0000564711af52e1 in pfs_spawn_thread (arg=0x564713b7d150) at /data/src/10.3/storage/perfschema/pfs.cc:1862
      #42 0x00007f625e131494 in start_thread (arg=0x7f62557a1700) at pthread_create.c:333
      #43 0x00007f625c51793f in clone () from /lib/x86_64-linux-gnu/libc.so.6
      

      Test case based on alice's reproducer from the comment

      --source include/have_innodb.inc
       
      CREATE SEQUENCE s1 ENGINE=InnoDB;
      ALTER TABLE s1 FORCE;
      CREATE TABLE t1 (a INT) ENGINE=MyISAM;
      CREATE TABLE t2 (b VARCHAR(64)) ENGINE=MyISAM;
      CREATE TRIGGER tr1 BEFORE INSERT ON t1 FOR EACH ROW INSERT INTO t2 SELECT TABLE_NAME FROM INFORMATION_SCHEMA.PARTITIONS;
      INSERT INTO t1 VALUES (1);
       
      # Cleanup
      DROP TABLE t1, t2, s1;
      

      Reproducible with at least MyISAM and Aria for base tables, and with InnoDB for the sequence; but not vice versa.
      No visible effect on a non-debug build.

      Attachments

        1. mysql_db.sql
          488 kB
          Alice Sherepa
        2. test_db.sql
          7 kB
          Alice Sherepa

        Activity

          robertbindar,

          Sure it is. Everything that is allowed is allowed, and unlike many, this operation is not even meaningless. It's still a table, you might want to have it rebuilt on whatever reason, ALTER... FORCE is the straightforward way to attempt to do so.

          elenst Elena Stepanova added a comment - robertbindar , Sure it is. Everything that is allowed is allowed, and unlike many, this operation is not even meaningless. It's still a table, you might want to have it rebuilt on whatever reason, ALTER... FORCE is the straightforward way to attempt to do so.
          robertbindar Robert Bindar added a comment - - edited

          Thanks for the quick reply, elenst.
          I can't see any particular use case for running ALTER .. FORCE on a sequence except for dropping the current cache of the sequence, and couldn't find ALTER .. FORCE in the list of allowed table operations for sequences here, this is where my question came from.
          The bug is not easy to trace, I can't simplify the test case anymore and still get a crash from the server. So I was trying to see if maybe ALTER .. FORCE has side effects because it wasn't designed to be executed on sequences.

          robertbindar Robert Bindar added a comment - - edited Thanks for the quick reply, elenst . I can't see any particular use case for running ALTER .. FORCE on a sequence except for dropping the current cache of the sequence, and couldn't find ALTER .. FORCE in the list of allowed table operations for sequences here , this is where my question came from. The bug is not easy to trace, I can't simplify the test case anymore and still get a crash from the server. So I was trying to see if maybe ALTER .. FORCE has side effects because it wasn't designed to be executed on sequences.
          elenst Elena Stepanova added a comment - - edited

          It was most certainly not designed to be executed on sequences, as it was implemented years before sequences. The goal is to adjust it so that it could work with the new stuff.
          If you have a strong opinion that ALTER ... FORCE is useless for sequences, you can raise it and discuss with serg the possibility of forbidding it (throwing an error that it is not allowed for sequences). I'm not going to argue if you come to such an agreement, although I imagine it might be a bit problematic since it's already well after GA for 10.3.

          For test simplification – there are only 6 primary SQL statements in that test, it rarely gets much better than that.

          elenst Elena Stepanova added a comment - - edited It was most certainly not designed to be executed on sequences, as it was implemented years before sequences. The goal is to adjust it so that it could work with the new stuff. If you have a strong opinion that ALTER ... FORCE is useless for sequences, you can raise it and discuss with serg the possibility of forbidding it (throwing an error that it is not allowed for sequences). I'm not going to argue if you come to such an agreement, although I imagine it might be a bit problematic since it's already well after GA for 10.3. For test simplification – there are only 6 primary SQL statements in that test, it rarely gets much better than that.
          robertbindar Robert Bindar added a comment -

          I don't have a strong opinion on ALTER .. FORCE being useless, mostly probably there are reasons I don't yet understand for it not being silently ignored / forbidden.

          robertbindar Robert Bindar added a comment - I don't have a strong opinion on ALTER .. FORCE being useless, mostly probably there are reasons I don't yet understand for it not being silently ignored / forbidden.
          robertbindar Robert Bindar added a comment -

          Merged with 3aa2a739209a021ba2e542e4d6c7c29ccecf97a0.

          robertbindar Robert Bindar added a comment - Merged with 3aa2a739209a021ba2e542e4d6c7c29ccecf97a0.

          People

            monty Michael Widenius
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            3 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.