[MDEV-21405] Assertion `(flags & ulint(~BTR_KEEP_IBUF_BITMAP)) == BTR_NO_LOCKING_FLAG' failed in btr_cur_pessimistic_insert Created: 2019-12-29  Updated: 2019-12-30  Resolved: 2019-12-30

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.3
Fix Version/s: 10.3.22

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: debug

Issue Links:
Relates
relates to MDEV-17820 Assertion `(flags & ulint(~BTR_KEEP_I... Closed

 Description    

--source include/have_innodb.inc
 
 
 
CREATE TABLE t1 (a INT DEFAULT 0) ENGINE=InnoDB ROW_FORMAT=REDUNDANT;
 
INSERT INTO t1 () VALUES
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),
 
    (),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),();
 
ALTER TABLE t1 ADD b INT;
 
ALTER TABLE t1 ADD c DOUBLE;
 
ALTER TABLE t1 DROP b;
 
ALTER TABLE t1 ADD d SMALLINT;
 
ALTER TABLE t1 ADD e MEDIUMINT;
 
INSERT INTO t1 (d,e) VALUES
 
    (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(0,0),
 
    (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(0,0);
 
DELETE FROM t1 LIMIT 9;
 
INSERT INTO t1 (d,e) VALUES
 
    (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(0,0),
 
    (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(0,0);
 
ALTER TABLE t1 ADD COLUMN f INT;
 
INSERT INTO t1 () VALUES ();
 
ALTER TABLE t1 ADD COLUMN g BINARY(40) DEFAULT '';
 
 
 
# Cleanup
 
DROP TABLE t1;

10.3 808bc919

 
mysqld: /data/src/10.3/storage/innobase/btr/btr0cur.cc:3669: dberr_t btr_cur_pessimistic_insert(ulint, btr_cur_t*, offset_t**, mem_heap_t**, dtuple_t*, rec_t**, big_rec_t**, ulint, que_thr_t*, mtr_t*): Assertion `(flags & ulint(~BTR_KEEP_IBUF_BITMAP)) == BTR_NO_LOCKING_FLAG' failed.
 
191229 22:08:17 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007f2fff43ef12 in __GI___assert_fail (assertion=0x55e0b4e28818 "(flags & ulint(~BTR_KEEP_IBUF_BITMAP)) == BTR_NO_LOCKING_FLAG", file=0x55e0b4e26e18 "/data/src/10.3/storage/innobase/btr/btr0cur.cc", line=3669, function=0x55e0b4e2d260 <btr_cur_pessimistic_insert(unsigned long, btr_cur_t*, unsigned short**, mem_block_info_t**, dtuple_t*, unsigned char**, big_rec_t**, unsigned long, que_thr_t*, mtr_t*)::__PRETTY_FUNCTION__> "dberr_t btr_cur_pessimistic_insert(ulint, btr_cur_t*, offset_t**, mem_heap_t**, dtuple_t*, rec_t**, big_rec_t**, ulint, que_thr_t*, mtr_t*)") at assert.c:101
 
#8  0x000055e0b472d19d in btr_cur_pessimistic_insert (flags=7, cursor=0x7f2ff87dc6b0, offsets=0x7f2ff87dc620, heap=0x7f2ff87dc628, entry=0x7f2fa804ced8, rec=0x7f2ff87dc508, big_rec=0x7f2ff87dc4f0, n_ext=0, thr=0x0, mtr=0x7f2ff87dc7c0) at /data/src/10.3/storage/innobase/btr/btr0cur.cc:3669
 
#9  0x000055e0b4732150 in btr_cur_pessimistic_update (flags=10, cursor=0x7f2ff87dc6b0, offsets=0x7f2ff87dc620, offsets_heap=0x7f2ff87dc628, entry_heap=0x7f2fa8047e20, big_rec=0x7f2ff87dc630, update=0x7f2fa804ccc0, cmpl_info=1, thr=0x7f2fa804cc00, trx_id=80, mtr=0x7f2ff87dc7c0) at /data/src/10.3/storage/innobase/btr/btr0cur.cc:4907
 
#10 0x000055e0b44a4050 in innobase_add_instant_try (ctx=0x7f2fa8014738, altered_table=0x7f2fa804b230, table=0x7f2fa80442c0, trx=0x7f2ff92d61c8) at /data/src/10.3/storage/innobase/handler/handler0alter.cc:4412
 
#11 0x000055e0b44bd832 in commit_try_norebuild (ha_alter_info=0x7f2ff87de1d0, ctx=0x7f2fa8014738, altered_table=0x7f2fa804b230, old_table=0x7f2fa80442c0, trx=0x7f2ff92d61c8, table_name=0x7f2fa804117d "t1") at /data/src/10.3/storage/innobase/handler/handler0alter.cc:8794
 
#12 0x000055e0b44b50f3 in ha_innobase::commit_inplace_alter_table (this=0x7f2fa80a4ba8, altered_table=0x7f2fa804b230, ha_alter_info=0x7f2ff87de1d0, commit=true) at /data/src/10.3/storage/innobase/handler/handler0alter.cc:9462
 
#13 0x000055e0b42413c7 in handler::ha_commit_inplace_alter_table (this=0x7f2fa80a4ba8, altered_table=0x7f2fa804b230, ha_alter_info=0x7f2ff87de1d0, commit=true) at /data/src/10.3/sql/handler.cc:4576
 
#14 0x000055e0b3ffecfb in mysql_inplace_alter_table (thd=0x7f2fa8000af0, table_list=0x7f2fa8012928, table=0x7f2fa80442c0, altered_table=0x7f2fa804b230, ha_alter_info=0x7f2ff87de1d0, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=0x7f2ff87de340, alter_ctx=0x7f2ff87de8f0) at /data/src/10.3/sql/sql_table.cc:7678
 
#15 0x000055e0b400546b in mysql_alter_table (thd=0x7f2fa8000af0, new_db=0x7f2fa80051d8, new_name=0x7f2fa8005598, create_info=0x7f2ff87df4e0, table_list=0x7f2fa8012928, alter_info=0x7f2ff87df420, order_num=0, order=0x0, ignore=false) at /data/src/10.3/sql/sql_table.cc:9918
 
#16 0x000055e0b4093799 in Sql_cmd_alter_table::execute (this=0x7f2fa8013168, thd=0x7f2fa8000af0) at /data/src/10.3/sql/sql_alter.cc:500
 
#17 0x000055e0b3f25320 in mysql_execute_command (thd=0x7f2fa8000af0) at /data/src/10.3/sql/sql_parse.cc:6031
 
#18 0x000055e0b3f2aa81 in mysql_parse (thd=0x7f2fa8000af0, rawbuf=0x7f2fa8012818 "ALTER TABLE t1 ADD COLUMN g BINARY(40) DEFAULT ''", length=49, parser_state=0x7f2ff87e05e0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:7818
 
#19 0x000055e0b3f175cd in dispatch_command (command=COM_QUERY, thd=0x7f2fa8000af0, packet=0x7f2fa81656a1 "ALTER TABLE t1 ADD COLUMN g BINARY(40) DEFAULT ''", packet_length=49, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1856
 
#20 0x000055e0b3f15f15 in do_command (thd=0x7f2fa8000af0) at /data/src/10.3/sql/sql_parse.cc:1401
 
#21 0x000055e0b408d89a in do_handle_one_connection (connect=0x55e0b7f67a10) at /data/src/10.3/sql/sql_connect.cc:1403
 
#22 0x000055e0b408d5fc in handle_one_connection (arg=0x55e0b7f67a10) at /data/src/10.3/sql/sql_connect.cc:1308
 
#23 0x000055e0b4a3c1d4 in pfs_spawn_thread (arg=0x55e0b7ead020) at /data/src/10.3/storage/perfschema/pfs.cc:1862
 
#24 0x00007f30013c74a4 in start_thread (arg=0x7f2ff87e1700) at pthread_create.c:456
 
#25 0x00007f2fff4fbd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Couldn't reproduce on 10.2 or 10.4.
No obvious effect on a non-debug build.

 Comments   
Comment by Marko Mäkelä [ 2019-12-30 ]

Here is a simplified test case (using a=NULL instead of a=0, because both use the same amount of storage in ROW_FORMAT=REDUNDANT):

--source include/have_innodb.inc
 
--source include/have_sequence.inc
 
 
 
CREATE TABLE t1 (a INT, c DOUBLE) ENGINE=InnoDB ROW_FORMAT=REDUNDANT;
 
INSERT INTO t1 SELECT NULL,NULL FROM seq_1_to_342;
 
ALTER TABLE t1 FORCE;
 
ALTER TABLE t1 ADD (d SMALLINT, e MEDIUMINT);
 
INSERT INTO t1 (d,e) VALUES
 
    (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(0,0),
 
    (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(0,0);
 
DELETE FROM t1 LIMIT 9;
 
INSERT INTO t1 (d,e) VALUES
 
    (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(0,0),
 
    (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(0,0);
 
ALTER TABLE t1 ADD COLUMN f INT;
 
INSERT INTO t1 () VALUES ();
 
ALTER TABLE t1 ADD COLUMN g BINARY(40) DEFAULT '';
 
 
 
# Cleanup
 
DROP TABLE t1;

The table rebuild after the first INSERT is necessary for the crash to occur. Note: in 10.3, DROP COLUMN requires a table rebuild, while in 10.4 it can be performed instantly, so my test should be more portable. The rebuild should affect the page fill factor. Even with my cleaned-up version of the test, I was unable to repeat a crash on 10.4.

Comment by Marko Mäkelä [ 2019-12-30 ]

In MariaDB 10.4.2, the failing debug assertion was changed as part of fixing MDEV-17820.

This looks like a too strict debug assertion to me. I think that we should simply backport that part of the MDEV-17820 fix to 10.3:

diff --git a/storage/innobase/btr/btr0cur.cc b/storage/innobase/btr/btr0cur.cc
 
index 5b14a19d9b8..328ed21841c 100644
 
--- a/storage/innobase/btr/btr0cur.cc
 
+++ b/storage/innobase/btr/btr0cur.cc
 
@@ -3666,8 +3666,8 @@ btr_cur_pessimistic_insert(
 
 		if (entry->info_bits & REC_INFO_MIN_REC_FLAG) {
 
 			ut_ad(entry->info_bits == REC_INFO_METADATA);
 
 			ut_ad(index->is_instant());
 
-			ut_ad((flags & ulint(~BTR_KEEP_IBUF_BITMAP))
 
-			      == BTR_NO_LOCKING_FLAG);
 
+			ut_ad(flags & BTR_NO_LOCKING_FLAG);
 
+			ut_ad(!(flags & BTR_CREATE_FLAG));
 
 		} else {
 
 			btr_search_update_hash_on_insert(
 
 				cursor, btr_get_search_latch(index));

Because this code is present in debug builds only, there is no impact for production builds.

Generated at Thu Feb 08 09:06:53 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.