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

Server crash in LEX::first_lists_tables_same

Details

    Description

      The test case is very non-deterministic, run with big --repeat=N.
      Don't put it into the regression suite, create a deterministic one instead.
      It usually fails for me within 20-200 attempts, but it can vary on different machines and builds.

      I don't know what relation it has to ORACLE mode/packages, to SHOW WARNINGS, and how the actions on the second table affect the outcome, but I couldn't get rid of any of those. Hopefully it can be simplified after the analysis.

      The failure is rr-able.

      --source include/have_sequence.inc
      		 
       
      		 
      CREATE TABLE t1 SELECT 'x' AS f1 FROM seq_1_to_100;
      		 
      CREATE TABLE t2 SELECT NULL AS f2;
      		 
       
      		 
      --connect (con1,localhost,root,,)
      		 
      DELETE FROM t1 WHERE f1 = 1;
      		 
       
      		 
      --connection default
      		 
      SET sql_mode= 'ORACLE';
      		 
      --delimiter $
      		 
      CREATE PACKAGE pkg IS PROCEDURE p; END $
      		 
      CREATE PACKAGE BODY pkg IS PROCEDURE p AS BEGIN ALTER TABLE t2 ENGINE=HEAP; END; END $
      		 
      --delimiter ;
      		 
      --send
      		 
        CALL pkg.p;
      		 
       
      		 
      --connection con1
      		 
      SHOW WARNINGS;
      		 
      INSERT INTO t2 VALUES (NULL);
      		 
       
      		 
      --connection default
      		 
      --reap
      		 
      CALL pkg.p;
      		 
       
      		 
      # Cleanup
      		 
      DROP TABLE t1, t2;
      		 
      DROP PACKAGE pkg;

      bb-11.0-oalter f9b33ac57

      		 
      (rr) bt
      		 
      #0  LEX::first_lists_tables_same (this=0x7f8358310b90) at /data/src/bb-11.0-oalter-debug/sql/sql_lex.cc:4497
      		 
      #1  0x000055dd0c750bcf in mysql_execute_command (thd=0x7f8358000dc8, is_called_from_prepared_stmt=false) at /data/src/bb-11.0-oalter-debug/sql/sql_parse.cc:3503
      		 
      #2  0x000055dd0c649e2b in sp_instr_stmt::exec_core (this=0x7f8358310478, thd=0x7f8358000dc8, nextp=0x7f83693a1f4c) at /data/src/bb-11.0-oalter-debug/sql/sp_head.cc:3857
      		 
      #3  0x000055dd0c649149 in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f83583104c0, thd=0x7f8358000dc8, nextp=0x7f83693a1f4c, open_tables=false, instr=0x7f8358310478)
      		 
          at /data/src/bb-11.0-oalter-debug/sql/sp_head.cc:3582
      		 
      #4  0x000055dd0c6499db in sp_instr_stmt::execute (this=0x7f8358310478, thd=0x7f8358000dc8, nextp=0x7f83693a1f4c) at /data/src/bb-11.0-oalter-debug/sql/sp_head.cc:3763
      		 
      #5  0x000055dd0c642977 in sp_head::execute (this=0x7f835830eb00, thd=0x7f8358000dc8, merge_da_on_success=true) at /data/src/bb-11.0-oalter-debug/sql/sp_head.cc:1459
      		 
      #6  0x000055dd0c64569c in sp_head::execute_procedure (this=0x7f835830eb00, thd=0x7f8358000dc8, args=0x7f8358006148) at /data/src/bb-11.0-oalter-debug/sql/sp_head.cc:2446
      		 
      #7  0x000055dd0c74ebaa in do_execute_sp (thd=0x7f8358000dc8, sp=0x7f835830eb00) at /data/src/bb-11.0-oalter-debug/sql/sql_parse.cc:3026
      		 
      #8  0x000055dd0c74f82c in Sql_cmd_call::execute (this=0x7f8358015598, thd=0x7f8358000dc8) at /data/src/bb-11.0-oalter-debug/sql/sql_parse.cc:3271
      		 
      #9  0x000055dd0c759a9d in mysql_execute_command (thd=0x7f8358000dc8, is_called_from_prepared_stmt=false) at /data/src/bb-11.0-oalter-debug/sql/sql_parse.cc:6001
      		 
      #10 0x000055dd0c75fc14 in mysql_parse (thd=0x7f8358000dc8, rawbuf=0x7f83580154d0 "CALL pkg.p", length=10, parser_state=0x7f83693a3370) at /data/src/bb-11.0-oalter-debug/sql/sql_parse.cc:8000
      		 
      #11 0x000055dd0c74b87f in dispatch_command (command=COM_QUERY, thd=0x7f8358000dc8, packet=0x7f835800ba59 "CALL pkg.p", packet_length=10, blocking=true)
      		 
          at /data/src/bb-11.0-oalter-debug/sql/sql_parse.cc:1894
      		 
      #12 0x000055dd0c74a1e6 in do_command (thd=0x7f8358000dc8, blocking=true) at /data/src/bb-11.0-oalter-debug/sql/sql_parse.cc:1407
      		 
      #13 0x000055dd0c93ca52 in do_handle_one_connection (connect=0x55dd1115d1d8, put_in_cache=true) at /data/src/bb-11.0-oalter-debug/sql/sql_connect.cc:1416
      		 
      #14 0x000055dd0c93c7c7 in handle_one_connection (arg=0x55dd111aa068) at /data/src/bb-11.0-oalter-debug/sql/sql_connect.cc:1318
      		 
      #15 0x000055dd0ce5c240 in pfs_spawn_thread (arg=0x55dd1115cc68) at /data/src/bb-11.0-oalter-debug/storage/perfschema/pfs.cc:2201
      		 
      #16 0x00007f836f8a7fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
      		 
      #17 0x00007f836f9278d0 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100

      Attachments

        Issue Links

          is caused by

          Task - A task that needs to be done. MDEV-16329 Engine-independent online ALTER TABLE

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed
          relates to

          Technical task - A technical task. MDEV-28808 Test MDEV-16329 (ALTER ONLINE TABLE) - Core server part

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            nikitamalyavin Nikita Malyavin added a comment - - edited

            This bug is about ONLINE ALTER TABLE + 2nd SP execution.
            SHOW WARNINGS and ORACLE PACKAGE were only aligning the timing, as well as copying 100-sized table.

            --source include/have_debug_sync.inc
            		 
             
            		 
            CREATE TABLE t1 ENGINE=myisam SELECT 1 AS x ;
            		 
            CREATE PROCEDURE p() ALTER TABLE t1 ENGINE=HEAP;
            		 
             
            		 
            SET debug_sync= 'alter_table_copy_end SIGNAL ended WAIT_FOR end';
            		 
            send CALL p;
            		 
             
            		 
            --connect (con1,localhost,root,,)
            		 
            SET debug_sync= 'now WAIT_FOR ended';
            		 
            INSERT INTO t1 VALUES (2);
            		 
            SET debug_sync= 'now SIGNAL end';
            		 
             
            		 
            --connection default
            		 
            --reap
            		 
            CALL p;
            		 
             
            		 
            DROP TABLE t1;

            nikitamalyavin Nikita Malyavin added a comment - - edited This bug is about ONLINE ALTER TABLE + 2nd SP execution. SHOW WARNINGS and ORACLE PACKAGE were only aligning the timing, as well as copying 100-sized table. --source include/have_debug_sync.inc   CREATE TABLE t1 ENGINE=myisam SELECT 1 AS x ; CREATE PROCEDURE p() ALTER TABLE t1 ENGINE=HEAP;   SET debug_sync= 'alter_table_copy_end SIGNAL ended WAIT_FOR end' ; send CALL p;   --connect (con1,localhost,root,,) SET debug_sync= 'now WAIT_FOR ended' ; INSERT INTO t1 VALUES (2); SET debug_sync= 'now SIGNAL end' ;   --connection default --reap CALL p;   DROP TABLE t1;
            nikitamalyavin Nikita Malyavin added a comment -

            Note:
            lex->query_tables was set to NULL in restore_empty_query_table_list when an online event is applied.
            Then lex->query_tables->prev_global was write-accessed in LEX::first_lists_tables_same, leading to a segfault.

            nikitamalyavin Nikita Malyavin added a comment - Note: lex->query_tables was set to NULL in restore_empty_query_table_list when an online event is applied. Then lex->query_tables->prev_global was write-accessed in LEX::first_lists_tables_same , leading to a segfault.

            People

              nikitamalyavin Nikita Malyavin
              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.