Details
-
Bug
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
10.6, 10.11, 11.4
Description
Set to minor, because we currently have ~13 open bugs for protocol assertion failures which nobody is fixing, and DELETE IGNORE from a sequence is not a normal real-life scenario, and it's only reproducible on 10.6-11.4 but not on 11.8+.
CREATE SEQUENCE s; |
DELETE IGNORE s FROM s; |
|
|
DROP SEQUENCE s; |
|
10.11 b0ee381c562a3642bd32df19c8727d6d40287be9 |
mariadbd: /data/bld/10.11-asan-ubsan/sql/protocol.cc:618: void Protocol::end_statement(): Assertion `0' failed.
|
260309 10:30:31 [ERROR] /share8t/bld/10.11-asan-ubsan/sql/mariadbd got signal 6 ;
|
|
|
#9 0x00007f64b9e45395 in __assert_fail_base (fmt=0x7f64b9fb9a90 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55fe74d1ac80 "0", file=file@entry=0x55fe74d1a9a0 "/data/bld/10.11-asan-ubsan/sql/protocol.cc", line=line@entry=618, function=function@entry=0x55fe74d1cb40 "void Protocol::end_statement()") at ./assert/assert.c:92
|
#10 0x00007f64b9e53eb2 in __GI___assert_fail (assertion=0x55fe74d1ac80 "0", file=0x55fe74d1a9a0 "/data/bld/10.11-asan-ubsan/sql/protocol.cc", line=618, function=0x55fe74d1cb40 "void Protocol::end_statement()") at ./assert/assert.c:101
|
#11 0x000055fe70e42f0f in Protocol::end_statement (this=this@entry=0x62c0000b0838) at /data/bld/10.11-asan-ubsan/sql/protocol.cc:618
|
#12 0x000055fe71478c18 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x62c0000b0218, packet=<optimized out>, packet@entry=0x62900024e219 "DELETE IGNORE s FROM s", packet_length=packet_length@entry=22, blocking=blocking@entry=true) at /data/bld/10.11-asan-ubsan/sql/sql_parse.cc:2471
|
#13 0x000055fe7147d41e in do_command (thd=thd@entry=0x62c0000b0218, blocking=blocking@entry=true) at /data/bld/10.11-asan-ubsan/sql/sql_parse.cc:1434
|
#14 0x000055fe71c79db8 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x6080000039b8, put_in_cache=put_in_cache@entry=true) at /data/bld/10.11-asan-ubsan/sql/sql_connect.cc:1475
|
#15 0x000055fe71c7af15 in handle_one_connection (arg=0x6080000039b8) at /data/bld/10.11-asan-ubsan/sql/sql_connect.cc:1387
|
#16 0x000055fe7360076f in pfs_spawn_thread (arg=0x617000005b98) at /data/bld/10.11-asan-ubsan/storage/perfschema/pfs.cc:2201
|
#17 0x00007f64b9ea81c4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
|
#18 0x00007f64b9f2885c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
|
On a non-debug build this DELETE IGNORE doesn't throw any errors or warnings (maybe there should be a warning, as a non-ignore DELETE returns an error; but handling of IGNORE has never been very consistent).
The assertion failure stopped happening after a set of commits related to MDEV-30469 in 11.8
edd52b7fc7d MDEV-30469 Feature rebase
|
5e07d1abd45 MDEV-35848, MDEV-35568 Reintroduce delete_while_scanning for multi_delete
|
8ec275da162 (HEAD) MDEV-35955 Wrong result for UPDATE ... ORDER BY LIMIT which uses tmp.table
|
5001300bd48 MDEV-30469 Support ORDER BY and LIMIT for multi-table DELETE, index hints for single-table DELETE
|
02dc8615f2b MDEV-30469 (refactoring) Support ORDER BY and LIMIT for multi-table DELETE...
|
that is, it is still reproducible on 02dc8615f2b, not reproducible on edd52b7fc7d, and intermediate commits don't build. Given that MDEV-30469 is about multi-update delete, it seems likely that something was changed (maybe even inadvertently) to stop it from happening.