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

Alter sequence with second execution of prepare statement crashes server

Details

    Description

      Before changes in MDEV-28152 next testcase fails with 

      query 'execute stmt' failed: ER_SEQUENCE_INVALID_DATA (4085): Sequence 'test.s' has out of range value for options

      After changes it causes server crash.

      Testcase:

      create sequence s;
      		 
      show create sequence s;
      		 
       
      		 
      prepare stmt from 'alter sequence s maxvalue 123';
      		 
      execute stmt;
      		 
      execute stmt;
      		 
      deallocate prepare stmt;
      		 
       
      		 
      show create sequence s;
      		 
      drop sequence s;

      Stacktrace:

      Thread pointer: 0x7f34dc000dc8
      		 
      Attempting backtrace. You can use the following information to find out
      		 
      where mysqld died. If you see no messages after this, something went
      		 
      terribly wrong...
      		 
      stack_bottom = 0x7f34ec7a0bf8 thread_stack 0x49000
      		 
      mysys/stacktrace.c:215(my_print_stacktrace)[0x564f4996dcac]
      		 
      sql/signal_handler.cc:241(handle_fatal_signal)[0x564f490357e6]
      		 
      libc_sigaction.c:0(__restore_rt)[0x7f34f1a42520]
      		 
      nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7f34f1a969fc]
      		 
      posix/raise.c:27(__GI_raise)[0x7f34f1a42476]
      		 
      stdlib/abort.c:81(__GI_abort)[0x7f34f1a287f3]
      		 
      intl/loadmsgcat.c:1177(_nl_load_domain)[0x7f34f1a2871b]
      		 
      /lib/x86_64-linux-gnu/libc.so.6(+0x39e96)[0x7f34f1a39e96]
      		 
      sql/sql_sequence.cc:1112(Sql_cmd_alter_sequence::execute(THD*))[0x564f48f47e9c]
      		 
      sql/sql_parse.cc:5738(mysql_execute_command(THD*, bool))[0x564f48c28cd0]
      		 
      sql/sql_prepare.cc:5071(Prepared_statement::execute(String*, bool))[0x564f48c6b9ee]
      		 
      sql/sql_prepare.cc:4455(Prepared_statement::execute_loop(String*, bool, unsigned char*, unsigned char*))[0x564f48c699c4]
      		 
      sql/sql_prepare.cc:3481(mysql_sql_stmt_execute(THD*))[0x564f48c66e99]
      		 
      sql/sql_parse.cc:3941(mysql_execute_command(THD*, bool))[0x564f48c21ec2]
      		 
      sql/sql_parse.cc:7748(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x564f48c2ef30]
      		 
      sql/sql_parse.cc:1895(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x564f48c1bad1]
      		 
      sql/sql_parse.cc:1406(do_command(THD*, bool))[0x564f48c1a417]
      		 
      sql/sql_connect.cc:1418(do_handle_one_connection(CONNECT*, bool))[0x564f48e14e14]
      		 
      sql/sql_connect.cc:1322(handle_one_connection)[0x564f48e14b7d]
      		 
      perfschema/pfs.cc:2203(pfs_spawn_thread)[0x564f493ac2e5]
      		 
      nptl/pthread_create.c:442(start_thread)[0x7f34f1a94ac3]
      		 
      x86_64/clone3.S:83(__clone3)[0x7f34f1b26660]

      Attachments

        Issue Links

          blocks

          New Feature - A new feature of the product, which has yet to be developed. MDEV-28152 Features for sequence

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

          Bug - A problem which impairs or prevents the functions of the product. MDEV-33169 Alter sequence 2nd ps fails while alter sequence 2nd time (no ps) succeeds

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

          New Feature - A new feature of the product, which has yet to be developed. MDEV-28152 Features for sequence

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

          Activity

            Ascending order - Click to sort in descending order
            lstartseva Lena Startseva added a comment -

            The same problem is for stored procedure:

            create procedure p() alter sequence s maxvalue 123;
            		 
            call p;
            		 
            call p;
            		 
            drop procedure p;

            Stacktrace:

            Thread pointer: 0x7fe7c0000dc8
            		 
            Attempting backtrace. You can use the following information to find out
            		 
            where mysqld died. If you see no messages after this, something went
            		 
            terribly wrong...
            		 
            stack_bottom = 0x7fe7dc094bf8 thread_stack 0x49000
            		 
            mysys/stacktrace.c:215(my_print_stacktrace)[0x560f89c5fcac]
            		 
            sql/signal_handler.cc:241(handle_fatal_signal)[0x560f893277e6]
            		 
            libc_sigaction.c:0(__restore_rt)[0x7fe7e0c42520]
            		 
            nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7fe7e0c969fc]
            		 
            posix/raise.c:27(__GI_raise)[0x7fe7e0c42476]
            		 
            stdlib/abort.c:81(__GI_abort)[0x7fe7e0c287f3]
            		 
            intl/loadmsgcat.c:1177(_nl_load_domain)[0x7fe7e0c2871b]
            		 
            /lib/x86_64-linux-gnu/libc.so.6(+0x39e96)[0x7fe7e0c39e96]
            		 
            sql/sql_sequence.cc:1112(Sql_cmd_alter_sequence::execute(THD*))[0x560f89239e9c]
            		 
            sql/sql_parse.cc:5738(mysql_execute_command(THD*, bool))[0x560f88f1acd0]
            		 
            sql/sp_instr.cc:956(sp_instr_stmt::exec_core(THD*, unsigned int*))[0x560f891e74a5]
            		 
            sql/sp_instr.cc:296(sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int*, bool, sp_instr*, bool))[0x560f891e587e]
            		 
            sql/sp_instr.cc:476(sp_lex_keeper::validate_lex_and_exec_core(THD*, unsigned int*, bool, sp_lex_instr*))[0x560f891e5f4d]
            		 
            sql/sp_instr.cc:862(sp_instr_stmt::execute(THD*, unsigned int*))[0x560f891e7024]
            		 
            sql/sp_head.cc:1284(sp_head::execute(THD*, bool))[0x560f88e044d9]
            		 
            sql/sp_head.cc:2300(sp_head::execute_procedure(THD*, List<Item>*))[0x560f88e0725c]
            		 
            sql/sql_parse.cc:3031(do_execute_sp(THD*, sp_head*))[0x560f88f10ea2]
            		 
            sql/sql_parse.cc:3254(Sql_cmd_call::execute(THD*))[0x560f88f11b6e]
            		 
            sql/sql_parse.cc:5738(mysql_execute_command(THD*, bool))[0x560f88f1acd0]
            		 
            sql/sql_parse.cc:7748(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x560f88f20f30]
            		 
            sql/sql_parse.cc:1895(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x560f88f0dad1]
            		 
            sql/sql_parse.cc:1406(do_command(THD*, bool))[0x560f88f0c417]
            		 
            sql/sql_connect.cc:1418(do_handle_one_connection(CONNECT*, bool))[0x560f89106e14]
            		 
            sql/sql_connect.cc:1322(handle_one_connection)[0x560f89106b7d]
            		 
            perfschema/pfs.cc:2203(pfs_spawn_thread)[0x560f8969e2e5]
            		 
            nptl/pthread_create.c:442(start_thread)[0x7fe7e0c94ac3]
            		 
            x86_64/clone3.S:83(__clone3)[0x7fe7e0d26660]

            lstartseva Lena Startseva added a comment - The same problem is for stored procedure: create procedure p() alter sequence s maxvalue 123; call p; call p; drop procedure p; Stacktrace: Thread pointer: 0x7fe7c0000dc8 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7fe7dc094bf8 thread_stack 0x49000 mysys/stacktrace.c:215(my_print_stacktrace)[0x560f89c5fcac] sql/signal_handler.cc:241(handle_fatal_signal)[0x560f893277e6] libc_sigaction.c:0(__restore_rt)[0x7fe7e0c42520] nptl/pthread_kill.c:44(__pthread_kill_implementation)[0x7fe7e0c969fc] posix/raise.c:27(__GI_raise)[0x7fe7e0c42476] stdlib/abort.c:81(__GI_abort)[0x7fe7e0c287f3] intl/loadmsgcat.c:1177(_nl_load_domain)[0x7fe7e0c2871b] /lib/x86_64-linux-gnu/libc.so.6(+0x39e96)[0x7fe7e0c39e96] sql/sql_sequence.cc:1112(Sql_cmd_alter_sequence:: execute (THD*))[0x560f89239e9c] sql/sql_parse.cc:5738(mysql_execute_command(THD*, bool))[0x560f88f1acd0] sql/sp_instr.cc:956(sp_instr_stmt::exec_core(THD*, unsigned int *))[0x560f891e74a5] sql/sp_instr.cc:296(sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int *, bool, sp_instr*, bool))[0x560f891e587e] sql/sp_instr.cc:476(sp_lex_keeper::validate_lex_and_exec_core(THD*, unsigned int *, bool, sp_lex_instr*))[0x560f891e5f4d] sql/sp_instr.cc:862(sp_instr_stmt:: execute (THD*, unsigned int *))[0x560f891e7024] sql/sp_head.cc:1284(sp_head:: execute (THD*, bool))[0x560f88e044d9] sql/sp_head.cc:2300(sp_head::execute_procedure(THD*, List<Item>*))[0x560f88e0725c] sql/sql_parse.cc:3031(do_execute_sp(THD*, sp_head*))[0x560f88f10ea2] sql/sql_parse.cc:3254(Sql_cmd_call:: execute (THD*))[0x560f88f11b6e] sql/sql_parse.cc:5738(mysql_execute_command(THD*, bool))[0x560f88f1acd0] sql/sql_parse.cc:7748(mysql_parse(THD*, char *, unsigned int , Parser_state*))[0x560f88f20f30] sql/sql_parse.cc:1895(dispatch_command(enum_server_command, THD*, char *, unsigned int , bool))[0x560f88f0dad1] sql/sql_parse.cc:1406(do_command(THD*, bool))[0x560f88f0c417] sql/sql_connect.cc:1418(do_handle_one_connection( CONNECT *, bool))[0x560f89106e14] sql/sql_connect.cc:1322(handle_one_connection)[0x560f89106b7d] perfschema/pfs.cc:2203(pfs_spawn_thread)[0x560f8969e2e5] nptl/pthread_create.c:442(start_thread)[0x7fe7e0c94ac3] x86_64/clone3.S:83(__clone3)[0x7fe7e0d26660]
            ycp Yuchen Pei added a comment -

            As mentioned in MDEV-33169, the patch there fixes this ticket too:

            4d2224702fc upstream/bb-11.4-mdev-28152 MDEV-28152 Features for sequences
            		 
            09a710036b6 MDEV-33169 Reset sequence used fields after check in alter sequence

            ycp Yuchen Pei added a comment - As mentioned in MDEV-33169 , the patch there fixes this ticket too: 4d2224702fc upstream/bb-11.4-mdev-28152 MDEV-28152 Features for sequences 09a710036b6 MDEV-33169 Reset sequence used fields after check in alter sequence
            ycp Yuchen Pei added a comment - - edited

            With MDEV-33169 fixed for 10.4, this ticket is now blocked by the next merge that bubbles that fix to 11.5.

            ycp Yuchen Pei added a comment - - edited With MDEV-33169 fixed for 10.4, this ticket is now blocked by the next merge that bubbles that fix to 11.5.
            ycp Yuchen Pei added a comment -

            I confirm that the fix of MDEV-33169 fixes this one, i.e. testcases which were already included in the patch for that ticket remain passed after applying MDEV-28152 on 11.5.

            ycp Yuchen Pei added a comment - I confirm that the fix of MDEV-33169 fixes this one, i.e. testcases which were already included in the patch for that ticket remain passed after applying MDEV-28152 on 11.5.

            People

              ycp Yuchen Pei
              lstartseva Lena Startseva
              Votes:
              0 Vote for this issue
              Watchers:
              4 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.