[MDEV-18649] Assertion `supremum[7] == index.n_core_null_bytes' failed in btr_set_instant Created: 2019-02-19  Updated: 2019-02-20  Resolved: 2019-02-20

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

Type: Bug Priority: Major
Reporter: Matthias Leich Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: None

Attachments: File bs_5.test     HTML File prt    
Issue Links:
Relates
relates to MDEV-15563 Instant failure-free data type conver... Closed
relates to MDEV-18048 handler0alter.cc:393: void dict_table... Closed

 Description   

Problem found during RQG testing.

CREATE TABLE IF NOT EXISTS t4 (
col1 INT,
col2 INT,
col_int INTEGER,
col_string VARCHAR(19),
col_varchar VARCHAR(500),
col_text TEXT,
col_int_g INTEGER GENERATED ALWAYS AS (col_int) PERSISTENT,
col_string_g VARCHAR(13) GENERATED ALWAYS AS (SUBSTR(col_string,4,13)) PERSISTENT,
col_text_g TEXT GENERATED ALWAYS AS (SUBSTR(col_text,1,499)) PERSISTENT)
ENGINE = InnoDB ROW_FORMAT = Redundant;
# The assert disappears if using "ENGINE = InnoDB" and not "ROW_FORMAT = Redundant".
ALTER TABLE t4 ADD PRIMARY KEY (col_text(9));
ALTER TABLE t4 DROP PRIMARY KEY;
ALTER TABLE t4 CHANGE COLUMN col_text col_text TEXT;
INSERT INTO t4 (col1) VALUES (NULL);
ALTER TABLE t4 MODIFY COLUMN col1 INT AFTER col_int;
ALTER TABLE t4 ADD COLUMN col_text_g_copy TEXT
GENERATED ALWAYS AS (SUBSTR(col_text,1,499)) VIRTUAL AFTER col1;
ALTER TABLE t4 DROP COLUMN col_text_g;
ERROR HY000: Lost connection to MySQL server during query
DROP TABLE t4;
...
Version: '10.4.3-MariaDB-debug-log'  ...
mysqld: storage/innobase/btr/btr0btr.cc:1936: void btr_set_instant(buf_block_t*, const dict_index_t&, mtr_t*): Assertion `supremum[7] == index.n_core_null_bytes' failed.
190219 16:49:46 [ERROR] mysqld got signal 6 ;
...
Query (0x7f9b080145a0): ALTER TABLE t4 DROP COLUMN col_text_g
Connection ID (thread ID): 9
Status: NOT_KILLED
...
#3  <signal handler called>
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#5  0x00007f9b649fff5d in __GI_abort () at abort.c:90
#6  0x00007f9b649f5f17 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x558ed002f598 "supremum[7] == index.n_core_null_bytes", file=file@entry=0x558ed002e660 "storage/innobase/btr/btr0btr.cc", line=line@entry=1936, function=function@entry=0x558ed0033060 <btr_set_instant(buf_block_t*, dict_index_t const&, mtr_t*)::__PRETTY_FUNCTION__> "void btr_set_instant(buf_block_t*, const dict_index_t&, mtr_t*)") at assert.c:92
#7  0x00007f9b649f5fc2 in __GI___assert_fail (assertion=0x558ed002f598 "supremum[7] == index.n_core_null_bytes", file=0x558ed002e660 "storage/innobase/btr/btr0btr.cc", line=1936, function=0x558ed0033060 <btr_set_instant(buf_block_t*, dict_index_t const&, mtr_t*)::__PRETTY_FUNCTION__> "void btr_set_instant(buf_block_t*, const dict_index_t&, mtr_t*)") at assert.c:101
#8  0x0000558ecf8fcab8 in btr_set_instant (root=0x7f9b5dfe1e70, index=..., mtr=0x7f9b5dd17090) at storage/innobase/btr/btr0btr.cc:1936
#9  0x0000558ecf700013 in innobase_instant_try (ha_alter_info=0x7f9b5dd18a90, ctx=0x7f9b08016928, altered_table=0x7f9b08071b58, table=0x7f9b08043f68, trx=0x7f9b5e803268) at storage/innobase/handler/handler0alter.cc:5699
#10 0x0000558ecf71c2de in commit_try_norebuild (ha_alter_info=0x7f9b5dd18a90, ctx=0x7f9b08016928, altered_table=0x7f9b08071b58, old_table=0x7f9b08043f68, trx=0x7f9b5e803268, table_name=0x7f9b08071945 "t4") at storage/innobase/handler/handler0alter.cc:10129
#11 0x0000558ecf70e395 in ha_innobase::commit_inplace_alter_table (this=0x7f9b080e5e40, altered_table=0x7f9b08071b58, ha_alter_info=0x7f9b5dd18a90, commit=true) at storage/innobase/handler/handler0alter.cc:10794
#12 0x0000558ecf4a0c23 in handler::ha_commit_inplace_alter_table (this=0x7f9b080e5e40, altered_table=0x7f9b08071b58, ha_alter_info=0x7f9b5dd18a90, commit=true) at sql/handler.cc:4673
#13 0x0000558ecf23b8be in mysql_inplace_alter_table (thd=0x7f9b08000ce8, table_list=0x7f9b08014698, table=0x7f9b08043f68, altered_table=0x7f9b08071b58, ha_alter_info=0x7f9b5dd18a90, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=0x7f9b5dd18cc0, alter_ctx=0x7f9b5dd19270) at sql/sql_table.cc:7602
#14 0x0000558ecf2416f1 in mysql_alter_table (thd=0x7f9b08000ce8, new_db=0x7f9b080053f8, new_name=0x7f9b080057f8, create_info=0x7f9b5dd19e60, table_list=0x7f9b08014698, alter_info=0x7f9b5dd19da0, order_num=0, order=0x0, ignore=false) at sql/sql_table.cc:9700
#15 0x0000558ecf2ccb9f in Sql_cmd_alter_table::execute (this=0x7f9b08014d00, thd=0x7f9b08000ce8) at sql/sql_alter.cc:493
#16 0x0000558ecf16329f in mysql_execute_command (thd=0x7f9b08000ce8) at sql/sql_parse.cc:6330
#17 0x0000558ecf1686f2 in mysql_parse (thd=0x7f9b08000ce8, rawbuf=0x7f9b080145a0 "ALTER TABLE t4 DROP COLUMN col_text_g", length=37, parser_state=0x7f9b5dd1b1e0, is_com_multi=false, is_next_command=false) at sql/sql_parse.cc:8141
#18 0x0000558ecf153b02 in dispatch_command (command=COM_QUERY, thd=0x7f9b08000ce8, packet=0x7f9b0800a009 "ALTER TABLE t4 DROP COLUMN col_text_g", packet_length=37, is_com_multi=false, is_next_command=false) at sql/sql_parse.cc:1819
#19 0x0000558ecf15234a in do_command (thd=0x7f9b08000ce8) at sql/sql_parse.cc:1357
#20 0x0000558ecf2c6add in do_handle_one_connection (connect=0x558ed1a73be8) at sql/sql_connect.cc:1399
#21 0x0000558ecf2c6841 in handle_one_connection (arg=0x558ed1a73be8) at sql/sql_connect.cc:1302
#22 0x0000558ecfbf8c54 in pfs_spawn_thread (arg=0x558ed1aba1d8) at storage/perfschema/pfs.cc:1862
#23 0x00007f9b658a57fc in start_thread (arg=0x7f9b5dd1c700) at pthread_create.c:465
#24 0x00007f9b64adbb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
 
10.4 commit abd3c202f6227a46f50c0d93cb621c9ed1e499c0 2019-02-19
The problem was not repeatable on
- 10.3 commit e8b6c15010e6fffe17e27c165b8c60b51a8f66a7 2019-02-13
- 10.2 commit af6fdc13072cc310cf17fd3b28c749515d9c563c 2019-02-19



 Comments   
Comment by Marko Mäkelä [ 2019-02-20 ]

This looks like a regression from the first part of MDEV-15563 that implemented instant NOT NULL removal for ROW_FORMAT=REDUNDANT. A similar bug was fixed in MDEV-18048.

The failing assertion is bogus for ROW_FORMAT=REDUNDANT tables. The dict_index_t::n_core_null_bytes and dict_index_t::n_nullable do not matter for ROW_FORMAT=REDUNDANT, because in this format there is no separate null flag bitmap in the record header, and the null flags are instead embedded in the end-of-field pointers.

Comment by Marko Mäkelä [ 2019-02-20 ]

Minimal test case:

--source include/innodb_row_format.inc
CREATE TABLE t1 (a INT NOT NULL, b INT NOT NULL) ENGINE=InnoDB;
INSERT INTO t1 VALUES (0,0);
ALTER TABLE t1 MODIFY a INT AFTER b;
# Exploit MDEV-17468 to force the table definition to be reloaded
ALTER TABLE t1 ADD COLUMN v INT AS (a) VIRTUAL;
ALTER TABLE t1 MODIFY b INT NOT NULL AFTER a;
DROP TABLE t1;

Comment by Marko Mäkelä [ 2019-02-20 ]

This was a too tight debug assertion. No impact for non-debug builds.

Generated at Thu Feb 08 08:45:42 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.