[MDEV-33012] Alter sequence with second execution of prepare statement crashes server Created: 2023-12-13  Updated: 2024-01-30

Status: Open
Project: MariaDB Server
Component/s: Prepared Statements, Sequences
Affects Version/s: 11.4
Fix Version/s: 11.5

Type: Bug Priority: Critical
Reporter: Lena Startseva Assignee: Yuchen Pei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Blocks
blocks MDEV-28152 Features for sequence Stalled
is blocked by MDEV-33169 Alter sequence 2nd ps fails while alt... Closed
Problem/Incident
is caused by MDEV-28152 Features for sequence Stalled

 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]



 Comments   
Comment by Lena Startseva [ 2023-12-14 ]

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]

Comment by Yuchen Pei [ 2024-01-04 ]

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

Comment by Yuchen Pei [ 2024-01-09 ]

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

Generated at Thu Feb 08 10:35:44 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.