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

SIGSEGV's in dict_table_t::is_active_ddl (10.6, opt) and dict_table_t::is_native_online_ddl (10.7+, opt)

Details

    Description

      Looks related to, but offset from, MDEV-24706

      SET GLOBAL general_log='ON';
      		 
      CREATE OR REPLACE TABLE mysql.general_log (a INT);
      		 
      CREATE TEMPORARY TABLE t (c INT) ENGINE=InnoDB;;
      		 
      INSERT INTO t VALUES (1);
      		 
      SET GLOBAL log_output='TABLE';
      		 
      SET SESSION autocommit=0;
      		 
      UPDATE t SET c=0;
      		 
      TRUNCATE t;
      		 
      SELECT a;

      Leads to:

      11.7.0 5bbda9711131845ae6b4315a268b4d1710943a85 (Optimized)

      		 
      Core was generated by `/test/MD090924-mariadb-11.7.0-linux-x86_64-opt/bin/mariadbd --no-defaults --max'.
      		 
      Program terminated with signal SIGSEGV, Segmentation fault.
      		 
      #0  0x0000560c9e407f42 in dict_table_t::is_native_online_ddl (this=<optimized out>)at /test/server_opt/storage/innobase/include/dict0mem.h:2417
      		 
       
      		 
      warning: 2417	/test/server_opt/storage/innobase/include/dict0mem.h: No such file or directory
      		 
      [Current thread is 1 (LWP 2134335)]
      		 
      (gdb) bt
      		 
      #0  0x0000560c9e407f42 in dict_table_t::is_native_online_ddl (this=<optimized out>)at /test/server_opt/storage/innobase/include/dict0mem.h:2417
      		 
      #1  trx_t::rollback_low (this=this@entry=0x1475e5800b80, savept=savept@entry=0x1475e58014b8)at /test/server_opt/storage/innobase/trx/trx0roll.cc:159
      		 
      #2  0x0000560c9e406dc0 in trx_t::rollback (savept=0x1475e58014b8, this=0x1475e5800b80)at /test/server_opt/storage/innobase/trx/trx0roll.cc:183
      		 
      #3  trx_t::rollback (savept=0x1475e58014b8, this=0x1475e5800b80)at /test/server_opt/storage/innobase/trx/trx0roll.cc:170
      		 
      #4  trx_rollback_last_sql_stat_for_mysql (trx=trx@entry=0x1475e5800b80)at /test/server_opt/storage/innobase/trx/trx0roll.cc:314
      		 
      #5  0x0000560c9e2fa150 in innobase_rollback (hton=<optimized out>, thd=0x147588000c68, rollback_trx=<optimized out>)at /test/server_opt/storage/innobase/handler/ha_innodb.cc:4644
      		 
      #6  0x0000560c9dfd2038 in ha_rollback_trans (thd=thd@entry=0x147588000c68, all=all@entry=false) at /test/server_opt/sql/handler.cc:2336
      		 
      #7  0x0000560c9de8bb63 in trans_rollback_stmt (thd=thd@entry=0x147588000c68)at /test/server_opt/sql/transaction.cc:566
      		 
      #8  0x0000560c9dd38fc0 in mysql_execute_command (thd=thd@entry=0x147588000c68, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false)at /test/server_opt/sql/sql_parse.cc:5927
      		 
      #9  0x0000560c9dd3e39e in mysql_parse (thd=0x147588000c68, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/server_opt/sql/sql_parse.cc:7876
      		 
      #10 0x0000560c9dd40edd in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x147588000c68, packet=packet@entry=0x147588008869 "SELECT a", packet_length=packet_length@entry=8, blocking=blocking@entry=true)at /test/server_opt/sql/sql_parse.cc:1991
      		 
      #11 0x0000560c9dd42b3d in do_command (thd=0x147588000c68, blocking=blocking@entry=true) at /test/server_opt/sql/sql_parse.cc:1405
      		 
      #12 0x0000560c9de79d3f in do_handle_one_connection (connect=<optimized out>, connect@entry=0x560ca20424d8, put_in_cache=put_in_cache@entry=true)at /test/server_opt/sql/sql_connect.cc:1448
      		 
      #13 0x0000560c9de7a0b5 in handle_one_connection (arg=arg@entry=0x560ca20424d8)at /test/server_opt/sql/sql_connect.cc:1350
      		 
      #14 0x0000560c9e2417bf in pfs_spawn_thread (arg=0x560ca2068ad8)at /test/server_opt/storage/perfschema/pfs.cc:2198
      		 
      #15 0x00001475e8e9ca94 in start_thread (arg=<optimized out>)at ./nptl/pthread_create.c:447
      		 
      #16 0x00001475e8f29c3c in clone3 ()at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

      Bug confirmed present in: 10.6+, opt builds

      Observed stacks:

      SIGSEGV|dict_table_t::is_active_ddl|trx_t::rollback_low|trx_t::rollback|trx_t::rollback  # opt, 10.6 only
      		 
      SIGSEGV|dict_table_t::is_native_online_ddl|trx_t::rollback_low|trx_t::rollback|trx_t::rollback # opt, 10.7+
      		 
      thd->transaction->stmt.is_empty() || thd->in_sub_stmt|SIGABRT|mysql_execute_command|mysql_parse|dispatch_command|do_command

      However, the thd->transaction->stmt.is_empty() assertion is seen only in debug builds, and is MDEV-24706. The SIGSEGV's in dict_table_t::is_active_ddl and dict_table_t::is_native_online_ddl are new. The bug does not replay in MTR including with modifications, please use the CLI.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-24706 Assertion `thd->transaction->stmt.is_empty() || thd->in_sub_stmt' failed in mysql_execute_command (from mysql_parse) and in trans_check

          • Major - Major loss of function.
          • Confirmed

          Activity

            marko Marko Mäkelä added a comment -

            It looks like mysql.general_log must be an InnoDB table for this crash to occur. Here is a slightly revised test that reproduces the crash in mtr:

            --source include/have_innodb.inc
            		 
            SET GLOBAL general_log='ON';
            		 
            CREATE OR REPLACE TABLE mysql.general_log (a INT) ENGINE=InnoDB;
            		 
            CREATE TEMPORARY TABLE t (c INT) ENGINE=InnoDB;
            		 
            INSERT INTO t VALUES (1);
            		 
            SET GLOBAL log_output='TABLE';
            		 
            SET autocommit=0;
            		 
            UPDATE t SET c=0;
            		 
            TRUNCATE t;
            		 
            SELECT a;

            10.6 a74bea7ba99a8c215cf085ff7a9dd4bdabab51e8

            		 
            mysqltest: At line 10: query 'SELECT a' failed: <Unknown> (2013): Lost connection to server during query
            		 
            …
            		 
            2024-09-14 10:49:50 4 [ERROR] Failed to write to mysql.general_log: 
            2024-09-14 10:49:50 4 [ERROR] Failed to write to mysql.general_log: 
            2024-09-14 10:49:50 4 [ERROR] Failed to write to mysql.general_log: 
            2024-09-14 10:49:50 4 [ERROR] Failed to write to mysql.general_log: 
            240914 10:49:50 [ERROR] mysqld got signal 11 ;

            Curiously, if I replace the invalid statement SELECT a with ROLLBACK, there will be no crash. Similarly, if I replace SET autocommit=0 with BEGIN, it will not crash.

            I don’t think that the table mysql.general_log can possibly work as an InnoDB table due to various reasons, also including locking conflicts. It would seem to me that this kind of an incorrect CREATE OR REPLACE TABLE statement needs to be rejected, or the log writes must check that the storage engine is something that can be expected to work for this usage. As far as I understand, the default is ENGINE=CSV.

            This is not an InnoDB bug.

            marko Marko Mäkelä added a comment - It looks like mysql.general_log must be an InnoDB table for this crash to occur. Here is a slightly revised test that reproduces the crash in mtr : --source include/have_innodb.inc SET GLOBAL general_log= 'ON' ; CREATE OR REPLACE TABLE mysql.general_log (a INT ) ENGINE=InnoDB; CREATE TEMPORARY TABLE t (c INT ) ENGINE=InnoDB; INSERT INTO t VALUES (1); SET GLOBAL log_output= 'TABLE' ; SET autocommit=0; UPDATE t SET c=0; TRUNCATE t; SELECT a; 10.6 a74bea7ba99a8c215cf085ff7a9dd4bdabab51e8 mysqltest: At line 10: query 'SELECT a' failed: <Unknown> (2013): Lost connection to server during query … 2024-09-14 10:49:50 4 [ERROR] Failed to write to mysql.general_log: 2024-09-14 10:49:50 4 [ERROR] Failed to write to mysql.general_log: 2024-09-14 10:49:50 4 [ERROR] Failed to write to mysql.general_log: 2024-09-14 10:49:50 4 [ERROR] Failed to write to mysql.general_log: 240914 10:49:50 [ERROR] mysqld got signal 11 ; Curiously, if I replace the invalid statement SELECT a with ROLLBACK , there will be no crash. Similarly, if I replace SET autocommit=0 with BEGIN , it will not crash. I don’t think that the table mysql.general_log can possibly work as an InnoDB table due to various reasons, also including locking conflicts. It would seem to me that this kind of an incorrect CREATE OR REPLACE TABLE statement needs to be rejected, or the log writes must check that the storage engine is something that can be expected to work for this usage. As far as I understand, the default is ENGINE=CSV . This is not an InnoDB bug.

            People

              sanja Oleksandr Byelkin
              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.