Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Cannot Reproduce
-
10.4(EOL), 10.5, 10.6, 10.7(EOL)
Description
There are other infamous bugs for this assertion failure, this one probably doesn't explain any of them, unless somebody can come up with a scenario when an InnoDB table in pre-MDEV-371 versions would use a HASH key. Still, I'll link the other bugs for this assertion failure to it, so that it's easier to see all the alternatives when we ask users about specifics of their data.
--source include/have_innodb.inc
|
|
|
CREATE TABLE t1 ( |
a INT NOT NULL AUTO_INCREMENT, |
b char(8) NOT NULL DEFAULT '', |
UNIQUE KEY (b), |
UNIQUE KEY (a) USING HASH |
) ENGINE=InnoDB;
|
|
|
INSERT INTO t1 (b) VALUES (''); |
UPDATE t1 SET a = 0; |
|
|
# Cleanup
|
DROP TABLE t1; |
|
10.4 non-debug 6da14d7b |
2020-05-31 14:49:03 9 [ERROR] InnoDB: Record in index `a` of table `test`.`t1` was not found on update: TUPLE (info_bits=0, 2 fields): {[8] (0x00000104000002D0),[8] (0x2020202020202020)} at: COMPACT RECORD(info_bits=0, 2 fields): {[8] (0x00000104000002C4),[8] (0x2020202020202020)}
|
2020-05-31 14:49:03 0x7fb7a5468700 InnoDB: Assertion failure in file /data/src/10.4/storage/innobase/row/row0ins.cc line 218
|
InnoDB: Failing assertion: !cursor->index->is_committed()
|
|
|
#6 0x000055698a2428f2 in ut_dbg_assertion_failed (expr=expr@entry=0x55698ad8cd28 "!cursor->index->is_committed()", file=file@entry=0x55698ad8c840 "/data/src/10.4/storage/innobase/row/row0ins.cc", line=line@entry=218) at /data/src/10.4/storage/innobase/ut/ut0dbg.cc:60
|
#7 0x000055698a79c4f1 in row_ins_sec_index_entry_by_modify (mtr=0x7fb7a5463eb0, thr=0x7fb758045d98, entry=0x7fb758047bc8, heap=0x7fb758048440, offsets_heap=<optimized out>, offsets=0x7fb7a5462fc8, cursor=0x7fb7a54630a0, mode=2, flags=0) at /data/src/10.4/storage/innobase/row/row0ins.cc:218
|
#8 row_ins_sec_index_entry_low (flags=flags@entry=0, mode=mode@entry=2, index=index@entry=0x7fb758084748, offsets_heap=<optimized out>, offsets_heap@entry=0x7fb758047fd0, heap=heap@entry=0x7fb758048440, entry=entry@entry=0x7fb758047bc8, trx_id=0, thr=0x7fb758045d98) at /data/src/10.4/storage/innobase/row/row0ins.cc:3056
|
#9 0x000055698a79c9de in row_ins_sec_index_entry (index=index@entry=0x7fb758084748, entry=0x7fb758047bc8, thr=thr@entry=0x7fb758045d98, check_foreign=<optimized out>) at /data/src/10.4/storage/innobase/row/row0ins.cc:3271
|
#10 0x000055698a7d3417 in row_upd_sec_index_entry (node=node@entry=0x7fb7580c8a50, thr=thr@entry=0x7fb758045d98) at /data/src/10.4/storage/innobase/row/row0upd.cc:2520
|
#11 0x000055698a7d8acd in row_upd_sec_step (thr=0x7fb758045d98, node=0x7fb7580c8a50) at /data/src/10.4/storage/innobase/row/row0upd.cc:2547
|
#12 row_upd (thr=0x7fb758045d98, node=0x7fb7580c8a50) at /data/src/10.4/storage/innobase/row/row0upd.cc:3327
|
#13 row_upd_step (thr=thr@entry=0x7fb758045d98) at /data/src/10.4/storage/innobase/row/row0upd.cc:3442
|
#14 0x000055698a7aef34 in row_update_for_mysql (prebuilt=0x7fb7580c7f88) at /data/src/10.4/storage/innobase/row/row0mysql.cc:1889
|
#15 0x000055698a6ed4ff in ha_innobase::update_row (this=0x7fb7580c77b0, old_row=0x7fb7580815e0 "\377\001", new_row=0x7fb7580815c8 "\377") at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:8816
|
#16 0x000055698a547b85 in handler::ha_update_row (this=0x7fb7580c77b0, old_data=0x7fb7580815e0 "\377\001", new_data=0x7fb7580815c8 "\377") at /data/src/10.4/sql/handler.cc:6764
|
#17 0x000055698a3d4949 in mysql_update (thd=thd@entry=0x7fb7580009a8, table_list=<optimized out>, fields=..., values=..., conds=<optimized out>, order_num=<optimized out>, order=<optimized out>, limit=18446744073709551615, ignore=false, found_return=0x7fb7a5465880, updated_return=0x7fb7a5465940) at /data/src/10.4/sql/sql_update.cc:1056
|
#18 0x000055698a32c535 in mysql_execute_command (thd=thd@entry=0x7fb7580009a8) at /data/src/10.4/sql/sql_parse.cc:4376
|
#19 0x000055698a3311ca in mysql_parse (thd=thd@entry=0x7fb7580009a8, rawbuf=<optimized out>, length=19, parser_state=parser_state@entry=0x7fb7a5467580, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.4/sql/sql_parse.cc:7901
|
#20 0x000055698a333474 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7fb7580009a8, packet=packet@entry=0x7fb758007a19 "UPDATE t1 SET a = 0", packet_length=packet_length@entry=19, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.4/sql/sql_parse.cc:1842
|
#21 0x000055698a334cd6 in do_command (thd=0x7fb7580009a8) at /data/src/10.4/sql/sql_parse.cc:1360
|
#22 0x000055698a4128a2 in do_handle_one_connection (connect=connect@entry=0x55698ca8c308) at /data/src/10.4/sql/sql_connect.cc:1412
|
#23 0x000055698a41295d in handle_one_connection (arg=arg@entry=0x55698ca8c308) at /data/src/10.4/sql/sql_connect.cc:1316
|
#24 0x000055698aa54261 in pfs_spawn_thread (arg=0x55698c793388) at /data/src/10.4/storage/perfschema/pfs.cc:1869
|
#25 0x00007fb7ad3164a4 in start_thread (arg=0x7fb7a5468700) at pthread_create.c:456
|
#26 0x00007fb7ac394d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
|
|
10.4 debug 6da14d7b |
2020-05-31 14:50:32 9 [ERROR] InnoDB: Record in index `a` of table `test`.`t1` was not found on update: TUPLE (info_bits=0, 2 fields): {[8] (0x00000104000002D0),[8] (0x2020202020202020)} at: COMPACT RECORD(info_bits=0, 2 fields): {[8] (0x00000104000002C4),[8] (0x2020202020202020)}
|
mysqld: /data/src/10.4/storage/innobase/row/row0upd.cc:2423: dberr_t row_upd_sec_index_entry(upd_node_t*, que_thr_t*): Assertion `btr_validate_index(index, 0)' failed.
|
200531 14:50:32 [ERROR] mysqld got signal 6 ;
|
|
|
#7 0x00007fe555394f12 in __GI___assert_fail (assertion=0x55cb6b7b38cd "btr_validate_index(index, 0)", file=0x55cb6b7b3130 "/data/src/10.4/storage/innobase/row/row0upd.cc", line=2423, function=0x55cb6b7b5fa0 <row_upd_sec_index_entry(upd_node_t*, que_thr_t*)::__PRETTY_FUNCTION__> "dberr_t row_upd_sec_index_entry(upd_node_t*, que_thr_t*)") at assert.c:101
|
#8 0x000055cb6afb6b3a in row_upd_sec_index_entry (node=0x7fe504146d08, thr=0x7fe504069090) at /data/src/10.4/storage/innobase/row/row0upd.cc:2423
|
#9 0x000055cb6afb74e2 in row_upd_sec_step (node=0x7fe504146d08, thr=0x7fe504069090) at /data/src/10.4/storage/innobase/row/row0upd.cc:2547
|
#10 0x000055cb6afba4e0 in row_upd (node=0x7fe504146d08, thr=0x7fe504069090) at /data/src/10.4/storage/innobase/row/row0upd.cc:3327
|
#11 0x000055cb6afba926 in row_upd_step (thr=0x7fe504069090) at /data/src/10.4/storage/innobase/row/row0upd.cc:3442
|
#12 0x000055cb6af5857f in row_update_for_mysql (prebuilt=0x7fe504146200) at /data/src/10.4/storage/innobase/row/row0mysql.cc:1889
|
#13 0x000055cb6adb0f76 in ha_innobase::update_row (this=0x7fe50400b868, old_row=0x7fe50400b428 "\377\001", new_row=0x7fe50400b410 "\377") at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:8816
|
#14 0x000055cb6ab729a6 in handler::ha_update_row (this=0x7fe50400b868, old_data=0x7fe50400b428 "\377\001", new_data=0x7fe50400b410 "\377") at /data/src/10.4/sql/handler.cc:6764
|
#15 0x000055cb6a91a60b in mysql_update (thd=0x7fe504000af0, table_list=0x7fe504013270, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7fe54a6fde40, updated_return=0x7fe54a6fdf00) at /data/src/10.4/sql/sql_update.cc:1056
|
#16 0x000055cb6a80b94f in mysql_execute_command (thd=0x7fe504000af0) at /data/src/10.4/sql/sql_parse.cc:4376
|
#17 0x000055cb6a8179cf in mysql_parse (thd=0x7fe504000af0, rawbuf=0x7fe504013198 "UPDATE t1 SET a = 0", length=19, parser_state=0x7fe54a6fe570, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:7901
|
#18 0x000055cb6a803f59 in dispatch_command (command=COM_QUERY, thd=0x7fe504000af0, packet=0x7fe504156e41 "UPDATE t1 SET a = 0", packet_length=19, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1842
|
#19 0x000055cb6a8026fb in do_command (thd=0x7fe504000af0) at /data/src/10.4/sql/sql_parse.cc:1360
|
#20 0x000055cb6a98a78a in do_handle_one_connection (connect=0x55cb6dc9c5c0) at /data/src/10.4/sql/sql_connect.cc:1412
|
#21 0x000055cb6a98a4d9 in handle_one_connection (arg=0x55cb6dc9c5c0) at /data/src/10.4/sql/sql_connect.cc:1316
|
#22 0x000055cb6b387fe3 in pfs_spawn_thread (arg=0x55cb6dc1a570) at /data/src/10.4/storage/perfschema/pfs.cc:1869
|
#23 0x00007fe55731d4a4 in start_thread (arg=0x7fe54a6ff700) at pthread_create.c:456
|
#24 0x00007fe555451d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
|
Reproducible on 10.4, 10.5.
Not reproducible on 10.3, because until MDEV-371 USING HASH was apparently ignored. Starting from MDEV-371, it makes a difference. It wasn't this assertion failure after the first push of MDEV-371, but SIGSEGV in row_sel_store_mysql_rec. I didn't bisect to find out when it mutated into the assertion failure, as it seems unimportant.
Slight tweaks in the table structure or DML can make the assertion failure go away and leave only the error "Record in index ... was not found".
Attachments
Issue Links
- is caused by
-
MDEV-371 Unique indexes for blobs
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
Activity
We observed a crash similar to this on 10.6.14 in a primary with read replica setup. The user bulk inserted about 4,000 records into as single table on their primary instance, and the read replica crashed while attempting to update a secondary hash index on the same index. The definition of the crashing table is:
CREATE TABLE `table1` (
|
`field1` bigint(20) unsigned NOT NULL AUTO_INCREMENT, |
`field2` date NOT NULL,
|
`field3` int(11) NOT NULL, |
`field4` varchar(200) DEFAULT NULL, |
`field5` int(11) NOT NULL DEFAULT 0, |
`field6` varchar(200) NOT NULL DEFAULT '', |
`field7` int(11) NOT NULL, |
`field8` varchar(200) CHARACTER SET latin1 COLLATE latin1_swedish_ci DEFAULT NULL, |
`field9` varchar(20) DEFAULT NULL, |
`field10` varchar(200) DEFAULT '', |
`field11` varchar(200) DEFAULT '', |
`field12` varchar(800) DEFAULT '', |
`field13` varchar(200) DEFAULT '', |
`field14` varchar(800) DEFAULT '', |
`field15` int(11) NOT NULL, |
`field16` int(11) NOT NULL, |
`field18` decimal(15,5) NOT NULL, |
PRIMARY KEY (`field1`),
|
UNIQUE KEY `field1_INDEX` (`field1`),
|
UNIQUE KEY `sec_hash_INDEX` (`field2`,`field3`,`field7`,`field11`,`field13`,`field14`,`field10`,`field12`,`field9`,`field5`) USING HASH,
|
KEY `field3_INDEX` (`field3`),
|
KEY `field11_INDEX` (`field11`),
|
KEY `field14_INDEX` (`field14`(768)), |
KEY `field2_INDEX` (`field2`),
|
KEY `field5_INDEX` (`field5`)
|
) ENGINE=InnoDB AUTO_INCREMENT=79021905 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci; |
The read replica crashes when updating the hash index `sec_hash_INDEX`.
When we looked at other MariaDB jiras, we thought that MDEV-27751 might be a match as well considering the comment by marko that linked MDEV-27751 to an issue with bulk inserts:
I suspect that this has something to do with
MDEV-24621.
Perhaps theMDEV-24622limitation was not being enforced?
Also see MDEV-35187 - InnoDB Data corruption and Assertion `0' failed in row_upd_sec_index_entry upon DELETE - in 10.11+
Does not repro in 10.5.28 694d91da896:
mysqltest: At line 6: query 'CREATE TABLE t1 (
|
a INT NOT NULL AUTO_INCREMENT,
|
b char(8) NOT NULL DEFAULT '',
|
UNIQUE KEY (b),
|
UNIQUE KEY (a) USING HASH
|
) ENGINE=InnoDB' failed: 1901: Function or expression 'AUTO_INCREMENT' cannot be used in the USING HASH clause of `a`
|
Both test cases from comments are still reproducible on 10.4, but not on 10.5+:
2023-09-28 18:49:57 0x7f11ac141300 InnoDB: Assertion failure in file /10.4/src/storage/innobase/row/row0ins.cc line 219InnoDB: Failing assertion: !cursor->index->is_committed()InnoDB: We intentionally generate a memory trap.InnoDB: Submit a detailed bug report to https://jira.mariadb.org/InnoDB: If you get repeated assertion failures or crashes, evenInnoDB: immediately after the mysqld startup, there may beInnoDB: corruption in the InnoDB tablespace. Please refer toInnoDB: https://mariadb.com/kb/en/library/innodb-recovery-modes/InnoDB: about forcing recovery.230928 18:49:57 [ERROR] mysqld got signal 6 ;This could be because you hit a bug. It is also possible that this binaryor one of the libraries it was linked against is corrupt, improperly built,or misconfigured. This error can also be caused by malfunctioning hardware.Server version: 10.4.32-MariaDB-debug-log source revision: 50a2e8b1892b6b8a276d4bd75a1a02148f9e6ff2sql/signal_handler.cc:238(handle_fatal_signal)[0x557e941767e9]sigaction.c:0(__restore_rt)[0x7f11c2d16420]ut/ut0dbg.cc:60(_sub_D_00099_0)[0x557e950a2a4e]row/row0ins.cc:220(row_ins_sec_index_entry_by_modify(unsigned long, unsigned long, btr_cur_t*, unsigned short**, mem_block_info_t*, mem_block_info_t*, dtuple_t const*, que_thr_t*, mtr_t*))[0x557e94e8937d]row/row0ins.cc:3149(row_ins_sec_index_entry_low(unsigned long, unsigned long, dict_index_t*, mem_block_info_t*, mem_block_info_t*, dtuple_t*, unsigned long, que_thr_t*))[0x557e94e99937]row/row0ins.cc:3361(row_ins_sec_index_entry(dict_index_t*, dtuple_t*, que_thr_t*, bool))[0x557e94e9ad2a]row/row0upd.cc:2571(row_upd_sec_index_entry(upd_node_t*, que_thr_t*))[0x557e94fa444e]row/row0upd.cc:2598(row_upd_sec_step(upd_node_t*, que_thr_t*))[0x557e94fa498f]row/row0upd.cc:3361(row_upd(upd_node_t*, que_thr_t*))[0x557e94fa9e02]row/row0upd.cc:3476(row_upd_step(que_thr_t*))[0x557e94faa913]row/row0mysql.cc:1804(row_update_for_mysql(row_prebuilt_t*))[0x557e94eeb17a]handler/ha_innodb.cc:8954(ha_innobase::update_row(unsigned char const*, unsigned char const*))[0x557e94b74026]sql/handler.cc:6915(handler::ha_update_row(unsigned char const*, unsigned char const*))[0x557e941b1bd7]sql/sql_update.cc:2600(multi_update::send_data(List<Item>&))[0x557e93ca48b2]sql/sql_select.cc:22098(end_send(JOIN*, st_join_table*, bool))[0x557e93b0d031]sql/sql_select.cc:21129(evaluate_join_record(JOIN*, st_join_table*, int))[0x557e93b053df]sql/sql_select.cc:20941(sub_select(JOIN*, st_join_table*, bool))[0x557e93b0437a]sql/sql_select.cc:21129(evaluate_join_record(JOIN*, st_join_table*, int))[0x557e93b053df]sql/sql_select.cc:20902(sub_select(JOIN*, st_join_table*, bool))[0x557e93b03d14]sql/sql_select.cc:20423(do_select(JOIN*, Procedure*))[0x557e93b01aba]sql/sql_select.cc:4605(JOIN::exec_inner())[0x557e93a8f602]sql/sql_select.cc:4388(JOIN::exec())[0x557e93a8cc2e]sql/sql_select.cc:4828(mysql_select(THD*, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x557e93a90e0e]sql/sql_update.cc:1970(mysql_multi_update(THD*, TABLE_LIST*, List<Item>*, List<Item>*, Item*, unsigned long long, enum_duplicates, bool, st_select_lex_unit*, st_select_lex*, multi_update**))[0x557e93c9e0b1]sql/sql_parse.cc:4532(mysql_execute_command(THD*))[0x557e939be3bd]sql/sql_parse.cc:8012(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x557e939d6c07]sql/sql_parse.cc:1860(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x557e939ad02d]sql/sql_parse.cc:1378(do_command(THD*))[0x557e939a9b58]sql/sql_connect.cc:1420(do_handle_one_connection(CONNECT*))[0x557e93db77fd]sql/sql_connect.cc:1325(handle_one_connection)[0x557e93db70a1]perfschema/pfs.cc:1871(pfs_spawn_thread)[0x557e94a6199a]nptl/pthread_create.c:478(start_thread)[0x7f11c2d0a609]Query (0x62b0000a1290): UPDATE t1 JOIN t2 SET t1.f = t2.a