Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.5, 10.6, 10.11, 11.4, 11.8, 12.0
Description
I'm not setting it to critical even though it's a recent regression, because CHAR(0) isn't a realistic use case (I hope).
--source include/have_innodb.inc
|
|
CREATE TABLE t (id INT PRIMARY KEY) ENGINE=innodb; |
--error 0,ER_WRONG_KEY_COLUMN
|
ALTER TABLE t MODIFY id CHAR(0); |
UPDATE t SET id = 1; |
|
DROP TABLE t; |
10.5 da20e4d8a57f0fd957edcaa50299173ccc8cac86 |
mariadbd: /data/bld/10.5-asan/storage/innobase/handler/ha_innodb.cc:8859: virtual int ha_innobase::index_read(uchar*, const uchar*, uint, ha_rkey_function): Assertion `key_len != 0 || find_flag != HA_READ_KEY_EXACT' failed.
|
250401 1:18:06 [ERROR] /share8t/bld/10.5-asan/sql/mariadbd got signal 6 ;
|
|
#9 0x00007f304ea53eb2 in __GI___assert_fail (assertion=0x56452421e8c0 "key_len != 0 || find_flag != HA_READ_KEY_EXACT", file=0x564524211320 "/data/bld/10.5-asan/storage/innobase/handler/ha_innodb.cc", line=8859, function=0x56452421e920 "virtual int ha_innobase::index_read(uchar*, const uchar*, uint, ha_rkey_function)") at ./assert/assert.c:101
|
#10 0x00005645228c5ac6 in ha_innobase::index_read (this=0x61d0002af8b8, buf=0x6190000fc3c8 "\377", '\276' <repeats 23 times>, "8\304\017", key_ptr=0x6190000fc648 '\276' <repeats 200 times>..., key_len=0, find_flag=HA_READ_KEY_EXACT) at /data/bld/10.5-asan/storage/innobase/handler/ha_innodb.cc:8859
|
#11 0x00005645228c9fa3 in ha_innobase::rnd_pos (this=0x61d0002af8b8, buf=0x6190000fc3c8 "\377", '\276' <repeats 23 times>, "8\304\017", pos=0x6190000fc648 '\276' <repeats 200 times>...) at /data/bld/10.5-asan/storage/innobase/handler/ha_innodb.cc:9428
|
#12 0x0000564521e49b88 in handler::ha_rnd_pos (this=0x61d0002af8b8, buf=0x6190000fc3c8 "\377", '\276' <repeats 23 times>, "8\304\017", pos=0x6190000fc648 '\276' <repeats 200 times>...) at /data/bld/10.5-asan/sql/handler.cc:3223
|
#13 0x00005645222ae7bb in rr_from_tempfile (info=0x7f30372218e0) at /data/bld/10.5-asan/sql/records.cc:535
|
#14 0x00005645214205a8 in READ_RECORD::read_record (this=0x7f30372218e0) at /data/bld/10.5-asan/sql/records.h:80
|
#15 0x0000564521900fa7 in mysql_update (thd=0x62b00007e218, table_list=0x62b000085338, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7f3037222030, updated_return=0x7f3037222050) at /data/bld/10.5-asan/sql/sql_update.cc:1024
|
#16 0x00005645215e7427 in mysql_execute_command (thd=0x62b00007e218) at /data/bld/10.5-asan/sql/sql_parse.cc:4507
|
#17 0x0000564521600f03 in mysql_parse (thd=0x62b00007e218, rawbuf=0x62b000085238 "UPDATE t SET id = 1", length=19, parser_state=0x7f3037222c70, is_com_multi=false, is_next_command=false) at /data/bld/10.5-asan/sql/sql_parse.cc:8252
|
#18 0x00005645215d60c6 in dispatch_command (command=COM_QUERY, thd=0x62b00007e218, packet=0x62900026c219 "UPDATE t SET id = 1", packet_length=19, is_com_multi=false, is_next_command=false) at /data/bld/10.5-asan/sql/sql_parse.cc:1891
|
#19 0x00005645215d2a59 in do_command (thd=0x62b00007e218) at /data/bld/10.5-asan/sql/sql_parse.cc:1375
|
#20 0x0000564521a30135 in do_handle_one_connection (connect=0x608000003eb8, put_in_cache=true) at /data/bld/10.5-asan/sql/sql_connect.cc:1386
|
#21 0x0000564521a2fc9b in handle_one_connection (arg=0x608000003e38) at /data/bld/10.5-asan/sql/sql_connect.cc:1298
|
#22 0x000056452268fdc8 in pfs_spawn_thread (arg=0x61500000e198) at /data/bld/10.5-asan/storage/perfschema/pfs.cc:2201
|
#23 0x00007f304eaa81c4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
|
#24 0x00007f304eb2885c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
|
The failure started happening after this commit in 10.5.28:
commit ecaedbe299fe11372c36319f9b732b81e9f54883 (HEAD)
|
Author: Nikita Malyavin
|
AuthorDate: Sat Oct 12 21:32:18 2024 +0200
|
Commit: Nikita Malyavin
|
CommitDate: Sun Jan 26 16:15:46 2025 +0100
|
|
MDEV-33658 1/2 Refactoring: extract Key length initialization
|
Before the commit, ALTER would return ER_WRONG_KEY_COLUMN. After the commit, ALTER succeeds, and the UPDATE causes the assertion failure.
A non-debug server hangs instead.
Attachments
Issue Links
- is caused by
-
MDEV-33658 Cannot add a foreign key on a table with a long UNIQUE multi-column index, that contains a foreign key as a prefix.
-
- Closed
-
- relates to
-
MDEV-36773 SIGSEGV's in row_search_mvcc and rec_get_bit_field_1, Assertions `cursor->pos_state == BTR_PCUR_IS_POSITIONED' and `m_prebuilt->search_tuple->n_fields > 0'
-
- Open
-
I also ran into this. Same hangs on optimized builds:
CS 12.0.0 22efc2c784e1b7199fb5804e6330168277ea7dce (Optimized) Build 04/04/2025
12.0.0-opt>SHOW FULL PROCESSLIST;
+----+------+-----------+------+---------+------+----------+-----------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+----+------+-----------+------+---------+------+----------+-----------------------+----------+
| 4 | root | localhost | test | Query | 260 | Updating | UPDATE t SET c=0 | 0.000 |
| 5 | root | localhost | test | Query | 0 | starting | SHOW FULL PROCESSLIST | 0.000 |
+----+------+-----------+------+---------+------+----------+-----------------------+----------+
2 rows in set (0.000 sec)