Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
11.8, 12.3, 13.1
-
None
Description
CREATE TABLE t (pk INT PRIMARY KEY, v VECTOR(2) NOT NULL, VECTOR(v)) ENGINE=MyISAM; |
INSERT INTO t VALUES (1,x'0000803f00000040'); |
|
|
--let $shutdown_timeout=0
|
--source include/restart_mysqld.inc
|
|
|
# The vector key remains corrupt due to MDEV-37142, so the underlying error is |
# (145): Table './test/t#i#01' is marked as crashed and should be repaired |
|
|
--error HA_ERR_CRASHED_ON_USAGE
|
UPDATE t SET pk = 2 WHERE pk = 0; |
|
|
DROP TABLE t; |
|
11.8 14362356d14b80242d60dceb9b34f988bbcc9945 |
mariadbd: /data/bld/11.8-asan-ubsan/sql/sql_error.cc:357: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
|
261010 22:28:43 [ERROR] /share8t/bld/11.8-asan-ubsan/sql/mariadbd got signal 6 ;
|
|
|
#10 0x00007f1d4a652ec2 in __GI___assert_fail (assertion=0x56429d828300 "!is_set() || (m_status == DA_OK_BULK && is_bulk_op())", file=0x56429d829680 "/data/bld/11.8-asan-ubsan/sql/sql_error.cc", line=357, function=0x56429d828360 "void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*)") at ./assert/assert.c:103
|
#11 0x0000564299b48575 in Diagnostics_area::set_ok_status (this=this@entry=0x62c0000c64b0, affected_rows=affected_rows@entry=0, last_insert_id=last_insert_id@entry=0, message=message@entry=0x7f1d3d96c390 "Rows matched: 0 Changed: 0 Warnings: 4") at /data/bld/11.8-asan-ubsan/sql/sql_error.cc:357
|
#12 0x0000564299959dcc in my_ok (thd=thd@entry=0x62c0000c0218, affected_rows_arg=0, id=id@entry=0, message=message@entry=0x7f1d3d96c390 "Rows matched: 0 Changed: 0 Warnings: 4") at /data/bld/11.8-asan-ubsan/sql/sql_class.h:6304
|
#13 0x000056429a3cedf6 in Sql_cmd_update::update_single_table (this=this@entry=0x62d0000faeb0, thd=thd@entry=0x62c0000c0218) at /data/bld/11.8-asan-ubsan/sql/sql_update.cc:1331
|
#14 0x000056429a3d1b4b in Sql_cmd_update::execute_inner (this=0x62d0000faeb0, thd=0x62c0000c0218) at /data/bld/11.8-asan-ubsan/sql/sql_update.cc:3250
|
#15 0x0000564299ef3b6d in Sql_cmd_dml::execute (this=0x62d0000faeb0, thd=0x62c0000c0218) at /data/bld/11.8-asan-ubsan/sql/sql_select.cc:34894
|
#16 0x0000564299d5f7b5 in mysql_execute_command (thd=thd@entry=0x62c0000c0218, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /data/bld/11.8-asan-ubsan/sql/sql_parse.cc:4455
|
#17 0x0000564299d79059 in mysql_parse (thd=thd@entry=0x62c0000c0218, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x7f1d3d96d9a0) at /data/bld/11.8-asan-ubsan/sql/sql_parse.cc:7938
|
#18 0x0000564299d8236b in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x62c0000c0218, packet=packet@entry=0x6290000eb219 "UPDATE t SET pk = 2 WHERE pk = 0", packet_length=packet_length@entry=32, blocking=blocking@entry=true) at /data/bld/11.8-asan-ubsan/sql/sql_parse.cc:1923
|
#19 0x0000564299d8e957 in do_command (thd=thd@entry=0x62c0000c0218, blocking=blocking@entry=true) at /data/bld/11.8-asan-ubsan/sql/sql_parse.cc:1431
|
#20 0x000056429a5df8d2 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x608000003a38, put_in_cache=put_in_cache@entry=true) at /data/bld/11.8-asan-ubsan/sql/sql_connect.cc:1515
|
#21 0x000056429a5e0a3b in handle_one_connection (arg=0x608000003a38) at /data/bld/11.8-asan-ubsan/sql/sql_connect.cc:1427
|
#22 0x000056429c07a30a in pfs_spawn_thread (arg=0x617000005f18) at /data/bld/11.8-asan-ubsan/storage/perfschema/pfs.cc:2198
|
#23 0x00007f1d4a6a71f5 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
|
#24 0x00007f1d4a7278ec in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
|
The assertion failure started happening after this merge in 11.8.3:
commit b565b3e7e041c480fd8013e3beec6b99544d6bf8
|
Merge: 982535b11f3 c4ed889b74e
|
Author: Sergei Golubchik
|
Date: Mon Jul 28 20:16:25 2025 +0200
|
|
|
Merge branch '11.4' into 11.8
|
It's a fairly big merge, so I didn't try to guess which commit brought it.
In any case, since before it the query was failing with HA_ERR_CRASHED_ON_USAGE (MDEV-37142), I don't consider it that much of a regression.
Attachments
Issue Links
- relates to
-
MDEV-37142 MyISAM auto-repair does not repair vector key
-
- Open
-