Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL)
Description
CREATE TABLE t1 (b INT); |
CREATE TEMPORARY TABLE t1 (a INT) ENGINE=Aria ROW_FORMAT=DYNAMIC; |
INSERT INTO t1 VALUES (1); |
DELETE FROM t1 LIMIT 2; |
OPTIMIZE TABLE t1; |
INSERT INTO t1 VALUES (1),(2); |
--error 0,ER_CRASHED_ON_USAGE
|
ALTER TABLE t1 CHANGE COLUMN IF EXISTS x x INT; |
ALTER TABLE t1; |
|
|
# Cleanup
|
DROP TEMPORARY TABLE t1; |
DROP TABLE t1; |
Please note that the first ALTER failing with ER_CRASHED_ON_USAGE is already a problem, and is the primary one; it is just masked in the test case to allow it to continue and reach the assertion failure.
MariaDB [test]> ALTER TABLE t1 CHANGE COLUMN IF EXISTS x x INT; |
ERROR 1194 (HY000): Table 't1' is marked as crashed and should be repaired |
|
10.2 b90918da |
mysqld: /data/src/10.2/sql/sql_error.cc:380: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
|
190525 17:07:02 [ERROR] mysqld got signal 6 ;
|
|
|
#6 0x00007f68d3bece67 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x562b4c0802b0 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=file@entry=0x562b4c0801e8 "/data/src/10.2/sql/sql_error.cc", line=line@entry=380, function=function@entry=0x562b4c080600 <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 0x00007f68d3becf12 in __GI___assert_fail (assertion=0x562b4c0802b0 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x562b4c0801e8 "/data/src/10.2/sql/sql_error.cc", line=380, function=0x562b4c080600 <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 0x0000562b4b5c5d51 in Diagnostics_area::set_ok_status (this=0x7f68bc005ca0, affected_rows=0, last_insert_id=0, message=0x7f68cdf1e290 "Records: 0 Duplicates: 0 Warnings: 2") at /data/src/10.2/sql/sql_error.cc:380
|
#9 0x0000562b4b578fa3 in my_ok (thd=0x7f68bc000b00, affected_rows=0, id=0, message=0x7f68cdf1e290 "Records: 0 Duplicates: 0 Warnings: 2") at /data/src/10.2/sql/sql_class.h:4534
|
#10 0x0000562b4b6c92f9 in mysql_alter_table (thd=0x7f68bc000b00, new_db=0x7f68bc012b30 "test", new_name=0x0, create_info=0x7f68cdf1ee60, table_list=0x7f68bc012520, alter_info=0x7f68cdf1edb0, order_num=0, order=0x0, ignore=false) at /data/src/10.2/sql/sql_table.cc:9091
|
#11 0x0000562b4b744e7f in Sql_cmd_alter_table::execute (this=0x7f68bc012b38, thd=0x7f68bc000b00) at /data/src/10.2/sql/sql_alter.cc:321
|
#12 0x0000562b4b5fbb96 in mysql_execute_command (thd=0x7f68bc000b00) at /data/src/10.2/sql/sql_parse.cc:6233
|
#13 0x0000562b4b600cba in mysql_parse (thd=0x7f68bc000b00, rawbuf=0x7f68bc012458 "ALTER TABLE t1", length=14, parser_state=0x7f68cdf20200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8020
|
#14 0x0000562b4b5ee50e in dispatch_command (command=COM_QUERY, thd=0x7f68bc000b00, packet=0x7f68bc08d891 "ALTER TABLE t1", packet_length=14, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1833
|
#15 0x0000562b4b5ece62 in do_command (thd=0x7f68bc000b00) at /data/src/10.2/sql/sql_parse.cc:1386
|
#16 0x0000562b4b73fb38 in do_handle_one_connection (connect=0x562b4e0154e0) at /data/src/10.2/sql/sql_connect.cc:1335
|
#17 0x0000562b4b73f8b8 in handle_one_connection (arg=0x562b4e0154e0) at /data/src/10.2/sql/sql_connect.cc:1241
|
#18 0x0000562b4bf6c008 in pfs_spawn_thread (arg=0x562b4e038790) at /data/src/10.2/storage/perfschema/pfs.cc:1862
|
#19 0x00007f68d57614a4 in start_thread (arg=0x7f68cdf21700) at pthread_create.c:456
|
#20 0x00007f68d3ca9d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
|
The second statement doesn't have to be ALTER, for example, SHOW CREATE TABLE and TRUNCATE also cause the assertion failure.
Other statements, such as SELECT, cause another ER_CRASHED_ON_USAGE.
Non-debug build doesn't crash, but it produces the same ER_CRASHED_ON_USAGE.
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
Activity
The test cases for the MDEV found several independent bugs in MariaDB server and Aria:
- If a temporary table was marked as crashed, it could never be deleted.
- Opening of a crashed temporary table gave an error message but the error was never forwarded to the caller which caused an assert() in my_ok()
- init_read_record() did mmap of all temporary tables, which is probably not a good idea as this area can potentially be very big. Changed code to only mmap internal temporary tables.
- mmap-ed tables where not unmapped in case of repair/optimize which caused bad data in table and crashes if the original table files where replaced with new ones (as the old mmap was still in place). Fixed by removing the mmap in case of repair.
Note: the test case and effect are very similar to
MDEV-17884. It's possible that the problem is unrelated to the engine, and one fix will fix them both.