[MDEV-22002] Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed upon CREATE TEMPORARY SEQUENCE under XA Created: 2020-03-22  Updated: 2020-05-27  Resolved: 2020-05-22

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Temporary, Sequences, XA
Affects Version/s: 10.3, 10.4, 10.5
Fix Version/s: 10.5.4, 10.3.24, 10.4.14

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: affects-tests, not-10.1, not-10.2


 Description   

XA BEGIN 'xid';
--error ER_XAER_RMFAIL
CREATE TEMPORARY SEQUENCE s;
 
# Cleanup
XA END 'xid';

10.3 debug fd5c36be

mysqld: /data/src/10.3/sql/sql_error.cc:335: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
200322 20:19:08 [ERROR] mysqld got signal 6 ;
 
#6  0x00007f694e299e67 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x564e4496cba8 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=file@entry=0x564e4496caf0 "/data/src/10.3/sql/sql_error.cc", line=line@entry=335, function=function@entry=0x564e4496cea0 <Diagnostics_area::set_ok_status(unsigned long long, unsigned long long, char const*)::__PRETTY_FUNCTION__> "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at assert.c:92
#7  0x00007f694e299f12 in __GI___assert_fail (assertion=0x564e4496cba8 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x564e4496caf0 "/data/src/10.3/sql/sql_error.cc", line=335, function=0x564e4496cea0 <Diagnostics_area::set_ok_status(unsigned long long, unsigned long long, char const*)::__PRETTY_FUNCTION__> "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at assert.c:101
#8  0x0000564e43ccd666 in Diagnostics_area::set_ok_status (this=0x7f6938006080, affected_rows=0, last_insert_id=0, message=0x0) at /data/src/10.3/sql/sql_error.cc:335
#9  0x0000564e43c78822 in my_ok (thd=0x7f6938000af0, affected_rows_arg=0, id=0, message=0x0) at /data/src/10.3/sql/sql_class.h:4892
#10 0x0000564e43e055f2 in Sql_cmd_create_table_like::execute (this=0x7f69380128f8, thd=0x7f6938000af0) at /data/src/10.3/sql/sql_table.cc:11263
#11 0x0000564e43d2091a in mysql_execute_command (thd=0x7f6938000af0) at /data/src/10.3/sql/sql_parse.cc:6030
#12 0x0000564e43d2607b in mysql_parse (thd=0x7f6938000af0, rawbuf=0x7f6938012818 "CREATE TEMPORARY SEQUENCE s", length=27, parser_state=0x7f69484985e0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:7817
#13 0x0000564e43d12c07 in dispatch_command (command=COM_QUERY, thd=0x7f6938000af0, packet=0x7f6938123201 "CREATE TEMPORARY SEQUENCE s", packet_length=27, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1856
#14 0x0000564e43d1154f in do_command (thd=0x7f6938000af0) at /data/src/10.3/sql/sql_parse.cc:1401
#15 0x0000564e43e890c8 in do_handle_one_connection (connect=0x564e46210110) at /data/src/10.3/sql/sql_connect.cc:1403
#16 0x0000564e43e88e2a in handle_one_connection (arg=0x564e46210110) at /data/src/10.3/sql/sql_connect.cc:1308
#17 0x0000564e44839368 in pfs_spawn_thread (arg=0x564e4622b1c0) at /data/src/10.3/storage/perfschema/pfs.cc:1869
#18 0x00007f69502224a4 in start_thread (arg=0x7f6948499700) at pthread_create.c:456
#19 0x00007f694e356d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Reproducible on 10.3-10.5.
The test case is not applicable to 10.2.
No obvious problem on a non-debug build.



 Comments   
Comment by Roel Van de Paar [ 2020-05-15 ]

Also saw the same.

SET GLOBAL READ_ONLY=1;
XA BEGIN '0';
CREATE TEMPORARY SEQUENCE s;

Leads to:

10.5.3 cfe5ee90c8e4b9dfa98a41fcd299197a59261be7

mysqld: /test/10.5_dbg/sql/sql_error.cc:335: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.

10.5.3 cfe5ee90c8e4b9dfa98a41fcd299197a59261be7

Core was generated by `/test/MD110520-mariadb-10.5.3-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'.
Program terminated with signal SIGABRT, Aborted.
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=6)
    at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
[Current thread is 1 (Thread 0x14601ff27700 (LWP 1558502))]
(gdb) bt
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
#1  0x0000562112fc8c11 in my_write_core (sig=sig@entry=6) at /test/10.5_dbg/mysys/stacktrace.c:518
#2  0x000056211276df8d in handle_fatal_signal (sig=6) at /test/10.5_dbg/sql/signal_handler.cc:329
#3  <signal handler called>
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5  0x000014601e66b801 in __GI_abort () at abort.c:79
#6  0x000014601e65b39a in __assert_fail_base (fmt=0x14601e7e27d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x562113137118 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=file@entry=0x5621131370c0 "/test/10.5_dbg/sql/sql_error.cc", line=line@entry=335, function=function@entry=0x562113137c40 <Diagnostics_area::set_ok_status(unsigned long long, unsigned long long, char const*)::__PRETTY_FUNCTION__> "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at assert.c:92
#7  0x000014601e65b412 in __GI___assert_fail (assertion=assertion@entry=0x562113137118 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=file@entry=0x5621131370c0 "/test/10.5_dbg/sql/sql_error.cc", line=line@entry=335, function=function@entry=0x562113137c40 <Diagnostics_area::set_ok_status(unsigned long long, unsigned long long, char const*)::__PRETTY_FUNCTION__> "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at assert.c:101
#8  0x000056211247ab19 in Diagnostics_area::set_ok_status (this=0x145ffd01ab88, affected_rows=affected_rows@entry=0, last_insert_id=last_insert_id@entry=0, message=message@entry=0x0) at /test/10.5_dbg/sql/sql_error.cc:335
#9  0x00005621125967d3 in my_ok (message=0x0, id=0, affected_rows_arg=0, thd=0x145ffd015088) at /test/10.5_dbg/sql/sql_class.h:5156
#10 Sql_cmd_create_table_like::execute (this=0x145ffd074180, thd=0x145ffd015088) at /test/10.5_dbg/sql/sql_table.cc:11886
#11 0x00005621124c9eda in mysql_execute_command (thd=thd@entry=0x145ffd015088) at /test/10.5_dbg/sql/sql_parse.cc:5912
#12 0x00005621124d1804 in mysql_parse (thd=thd@entry=0x145ffd015088, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x14601ff263e0, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.5_dbg/sql/sql_parse.cc:7957
#13 0x00005621124bdffd in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x145ffd015088, packet=packet@entry=0x145ffd067089 "CREATE TEMPORARY SEQUENCE s", packet_length=packet_length@entry=27, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /test/10.5_dbg/sql/sql_parse.cc:1839
#14 0x00005621124bc8cc in do_command (thd=0x145ffd015088) at /test/10.5_dbg/sql/sql_parse.cc:1358
#15 0x000056211261699d in do_handle_one_connection (connect=<optimized out>, connect@entry=0x145ffec433a8, put_in_cache=put_in_cache@entry=true) at /test/10.5_dbg/sql/sql_connect.cc:1411
#16 0x00005621126170b9 in handle_one_connection (arg=arg@entry=0x145ffec433a8) at /test/10.5_dbg/sql/sql_connect.cc:1313
#17 0x0000562112a7510a in pfs_spawn_thread (arg=0x14601dc45888) at /test/10.5_dbg/storage/perfschema/pfs.cc:2201
#18 0x000014601f34e6db in start_thread (arg=0x14601ff27700) at pthread_create.c:463
#19 0x000014601e74c88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug confirmed present in:
MariaDB: 10.3.23 (dbg), 10.4.13 (dbg), 10.5.2 (dbg), 10.5.3 (dbg), 10.5.4 (dbg)

Bug confirmed not present in:
MariaDB: 10.1.45 (dbg), 10.1.45 (opt), 10.2.32 (dbg), 10.2.32 (opt), 10.3.23 (opt), 10.4.13 (opt), 10.5.2 (opt), 10.5.3 (opt), 10.5.4 (opt)
MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.47 (dbg), 5.6.47 (opt), 5.7.29 (dbg), 5.7.29 (opt), 8.0.19 (dbg), 8.0.19 (opt)

Comment by Michael Widenius [ 2020-05-22 ]

Problem was that CREATE SEQUENCE didn't check return value of commit.

Comment by Roel Van de Paar [ 2020-05-27 ]

Filter removed from runs

Generated at Thu Feb 08 09:11:27 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.