Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.5, 10.6
Description
Note: MDEV-22048 is already in the tree, its test case now passes. I am a new one rather than re-opening MDEV-22048 because I'm not sure a fix for it will make it to 10.5.4, and we generally don't want to have separate fixes for the same bug in different release change logs.
Also, I'm not marking it as a regression this time, because according to MDEV-22048 analysis the underlying problem existed before, it surfaced because of the new assertion.
--source include/have_innodb.inc
|
--source include/have_binlog_format_row.inc
|
|
|
--connect (con1,localhost,root,,)
|
CREATE TABLE t1 (a INT) ENGINE=InnoDB; |
CREATE TRIGGER tr BEFORE UPDATE ON t1 FOR EACH ROW BEGIN END; |
LOCK TABLES t1 WRITE;
|
--error ER_TABLE_NOT_LOCKED
|
LOAD DATA INFILE 'x' INTO TABLE x; |
SET AUTOCOMMIT= OFF; |
INSERT INTO t1 VALUES (1); |
SAVEPOINT A;
|
COMMIT; |
--disconnect con1
|
|
|
--connect (con2,localhost,root,,)
|
SELECT 1; |
|
|
# Cleanup
|
--disconnect con2
|
--connection default
|
DROP TABLE t1; |
|
10.5 e290e5a7 |
mariadbd: /data/src/10.5/sql/sql_parse.cc:7484: void THD::reset_for_next_command(bool): Assertion `binlog_table_maps == 0 || locked_tables_mode == LTM_LOCK_TABLES' failed.
|
200616 17:34:45 [ERROR] mysqld got signal 6 ;
|
|
|
#7 0x00007f724ccfbf12 in __GI___assert_fail (assertion=0x555b5a16e870 "binlog_table_maps == 0 || locked_tables_mode == LTM_LOCK_TABLES", file=0x555b5a16d1c0 "/data/src/10.5/sql/sql_parse.cc", line=7484, function=0x555b5a170600 <THD::reset_for_next_command(bool)::__PRETTY_FUNCTION__> "void THD::reset_for_next_command(bool)") at assert.c:101
|
#8 0x0000555b593cd175 in THD::reset_for_next_command (this=0x7f720c000b18, do_clear_error=true) at /data/src/10.5/sql/sql_parse.cc:7483
|
#9 0x0000555b593ce62f in mysql_parse (thd=0x7f720c000b18, rawbuf=0x7f720c0126f0 "SELECT 1", length=8, parser_state=0x7f72421cf520, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:7934
|
#10 0x0000555b593babd1 in dispatch_command (command=COM_QUERY, thd=0x7f720c000b18, packet=0x7f720c008749 "SELECT 1", packet_length=8, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1875
|
#11 0x0000555b593b9309 in do_command (thd=0x7f720c000b18) at /data/src/10.5/sql/sql_parse.cc:1356
|
#12 0x0000555b5955e421 in do_handle_one_connection (connect=0x555b5de3be28, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1411
|
#13 0x0000555b5955e189 in handle_one_connection (arg=0x555b5de3be28) at /data/src/10.5/sql/sql_connect.cc:1313
|
#14 0x0000555b59a9888a in pfs_spawn_thread (arg=0x555b5dd1a368) at /data/src/10.5/storage/perfschema/pfs.cc:2201
|
#15 0x00007f724ec844a4 in start_thread (arg=0x7f72421d0700) at pthread_create.c:456
|
#16 0x00007f724cdb8d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
|
No obvious problem on a non-debug build.
Attachments
Issue Links
- relates to
-
-
- Closed
-