[MDEV-29003] Assertion `*err == DB_SUCCESS' failed in btr_page_split_and_insert Created: 2022-07-01  Updated: 2022-07-27  Resolved: 2022-07-26

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Storage Engine - InnoDB
Affects Version/s: N/A
Fix Version/s: 10.6.9, 10.7.5, 10.8.4, 10.9.2, 10.10.1

Type: Bug Priority: Critical
Reporter: Roel Van de Paar Assignee: Marko Mäkelä
Resolution: Duplicate Votes: 0
Labels: regression

Issue Links:
Duplicate
duplicates MDEV-28950 Assertion `*err == DB_SUCCESS' failed... Closed

 Description   

Issue not present in current 10.10 trunk. Present in bb-10.10-MDEV-28883. Present in debug builds only.

SET sql_mode='';
 
CREATE TABLE t (c1 INT, c2 CHAR(255)) ENGINE=InnoDB;
 
INSERT INTO t VALUES (0,'a');
 
ALTER TABLE t KEY_BLOCK_SIZE=2;
 
INSERT INTO t VALUES (1,'b'),(2,'c'),(3,'c');
 
SET GLOBAL innodb_compression_level=0;
 
INSERT INTO t VALUES (4,'d'),(5,'e'),(6,'f');
 
INSERT INTO t VALUES (7,'e');

Leads to:

10.10.0 2db18fdb3d68d906fbd188ec570a64502ba55849 (Debug)

 
mysqld: /test/bb-10.10-MDEV-28883_dbg/storage/innobase/btr/btr0btr.cc:2791: rec_t* btr_page_split_and_insert(ulint, btr_cur_t*, rec_offs**, mem_heap_t**, const dtuple_t*, ulint, mtr_t*, dberr_t*): Assertion `*err == DB_SUCCESS' failed.

10.10.0 2db18fdb3d68d906fbd188ec570a64502ba55849 (Debug)

 
Core was generated by `/test/MDEV-28883_MD280622-mariadb-10.10.0-linux-x86_64-dbg/bin/mysqld --no-defa'.
 
Program terminated with signal SIGABRT, Aborted.
 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
 
[Current thread is 1 (Thread 0x1490ad46a700 (LWP 4128068))]
 
(gdb) bt
 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
 
#1  0x00001490c5bea859 in __GI_abort () at abort.c:79
 
#2  0x00001490c5bea729 in __assert_fail_base (fmt=0x1490c5d80588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55e9524a0b13 "*err == DB_SUCCESS", file=0x55e9524a0f18 "/test/bb-10.10-MDEV-28883_dbg/storage/innobase/btr/btr0btr.cc", line=2791, function=<optimized out>) at assert.c:92
 
#3  0x00001490c5bfbfd6 in __GI___assert_fail (assertion=assertion@entry=0x55e9524a0b13 "*err == DB_SUCCESS", file=file@entry=0x55e9524a0f18 "/test/bb-10.10-MDEV-28883_dbg/storage/innobase/btr/btr0btr.cc", line=line@entry=2791, function=function@entry=0x55e9524a22d8 "rec_t* btr_page_split_and_insert(ulint, btr_cur_t*, rec_offs**, mem_heap_t**, const dtuple_t*, ulint, mtr_t*, dberr_t*)") at assert.c:101
 
#4  0x000055e951e9738c in btr_page_split_and_insert (flags=flags@entry=0, cursor=cursor@entry=0x1490ad467810, offsets=offsets@entry=0x1490ad4677f8, heap=heap@entry=0x1490ad4677f0, tuple=tuple@entry=0x1490740211f0, n_ext=n_ext@entry=0, mtr=0x1490ad467dc0, err=0x1490ad46773c) at /test/bb-10.10-MDEV-28883_dbg/storage/innobase/btr/btr0btr.cc:2791
 
#5  0x000055e951e9eb5c in btr_root_raise_and_insert (flags=flags@entry=0, cursor=cursor@entry=0x1490ad467810, offsets=offsets@entry=0x1490ad4677f8, heap=heap@entry=0x1490ad4677f0, tuple=tuple@entry=0x1490740211f0, n_ext=0, mtr=0x1490ad467dc0, err=0x1490ad46773c) at /test/bb-10.10-MDEV-28883_dbg/storage/innobase/btr/btr0btr.cc:1972
 
#6  0x000055e951ebc300 in btr_cur_pessimistic_insert (flags=flags@entry=0, cursor=cursor@entry=0x1490ad467810, offsets=offsets@entry=0x1490ad4677f8, heap=heap@entry=0x1490ad4677f0, entry=entry@entry=0x1490740211f0, rec=rec@entry=0x1490ad467808, big_rec=0x1490ad4677e8, n_ext=<optimized out>, thr=0x1490740283d0, mtr=0x1490ad467dc0) at /test/bb-10.10-MDEV-28883_dbg/storage/innobase/include/fil0fil.h:487
 
#7  0x000055e951dad681 in row_ins_clust_index_entry_low (flags=flags@entry=0, mode=<optimized out>, mode@entry=10, index=index@entry=0x14907407c470, n_uniq=n_uniq@entry=0, entry=entry@entry=0x1490740211f0, n_ext=n_ext@entry=0, thr=<optimized out>) at /test/bb-10.10-MDEV-28883_dbg/storage/innobase/row/row0ins.cc:2789
 
#8  0x000055e951dae250 in row_ins_clust_index_entry (index=index@entry=0x14907407c470, entry=entry@entry=0x1490740211f0, thr=thr@entry=0x1490740283d0, n_ext=n_ext@entry=0) at /test/bb-10.10-MDEV-28883_dbg/storage/innobase/row/row0ins.cc:3185
 
#9  0x000055e951dafeec in row_ins_index_entry (thr=0x1490740283d0, entry=0x1490740211f0, index=0x14907407c470) at /test/bb-10.10-MDEV-28883_dbg/storage/innobase/row/row0ins.cc:3305
 
#10 row_ins_index_entry_step (thr=0x1490740283d0, node=<optimized out>) at /test/bb-10.10-MDEV-28883_dbg/storage/innobase/row/row0ins.cc:3473
 
#11 row_ins (thr=0x1490740283d0, node=<optimized out>) at /test/bb-10.10-MDEV-28883_dbg/storage/innobase/row/row0ins.cc:3619
 
#12 row_ins_step (thr=thr@entry=0x1490740283d0) at /test/bb-10.10-MDEV-28883_dbg/storage/innobase/row/row0ins.cc:3759
 
#13 0x000055e951dd2864 in row_insert_for_mysql (mysql_rec=mysql_rec@entry=0x149074020908 "\371\a", prebuilt=0x149074027b80, ins_mode=ROW_INS_NORMAL) at /test/bb-10.10-MDEV-28883_dbg/storage/innobase/row/row0mysql.cc:1309
 
#14 0x000055e951c5d69d in ha_innobase::write_row (this=0x149074070240, record=0x149074020908 "\371\a") at /test/bb-10.10-MDEV-28883_dbg/storage/innobase/handler/ha_innodb.cc:7845
 
#15 0x000055e951948a81 in handler::ha_write_row (this=0x149074070240, buf=0x149074020908 "\371\a") at /test/bb-10.10-MDEV-28883_dbg/sql/handler.cc:7551
 
#16 0x000055e95160bee0 in write_record (thd=thd@entry=0x149074000db8, table=table@entry=0x149074020498, info=info@entry=0x1490ad468d60, sink=sink@entry=0x0) at /test/bb-10.10-MDEV-28883_dbg/sql/sql_insert.cc:2162
 
#17 0x000055e951616746 in mysql_insert (thd=thd@entry=0x149074000db8, table_list=<optimized out>, fields=@0x149074005ea8: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x55e952b1f700 <end_of_list>, last = 0x149074005ea8, elements = 0}, <No data fields>}, values_list=@0x149074005ef0: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x1490740149d0, last = 0x1490740149d0, elements = 1}, <No data fields>}, update_fields=@0x149074005ed8: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x55e952b1f700 <end_of_list>, last = 0x149074005ed8, elements = 0}, <No data fields>}, update_values=@0x149074005ec0: {<base_list> = {<Sql_alloc> = {<No data fields>}, first = 0x55e952b1f700 <end_of_list>, last = 0x149074005ec0, elements = 0}, <No data fields>}, duplic=DUP_ERROR, ignore=false, result=0x0) at /test/bb-10.10-MDEV-28883_dbg/sql/sql_insert.cc:1132
 
#18 0x000055e951659380 in mysql_execute_command (thd=thd@entry=0x149074000db8, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/bb-10.10-MDEV-28883_dbg/sql/sql_parse.cc:4442
 
#19 0x000055e951645ec5 in mysql_parse (thd=thd@entry=0x149074000db8, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x1490ad469460) at /test/bb-10.10-MDEV-28883_dbg/sql/sql_parse.cc:7797
 
#20 0x000055e95165341a in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x149074000db8, packet=packet@entry=0x14907400b6e9 "INSERT INTO t VALUES (7,'e')", packet_length=packet_length@entry=28, blocking=blocking@entry=true) at /test/bb-10.10-MDEV-28883_dbg/sql/sql_class.h:1364
 
#21 0x000055e951655b27 in do_command (thd=0x149074000db8, blocking=blocking@entry=true) at /test/bb-10.10-MDEV-28883_dbg/sql/sql_parse.cc:1405
 
#22 0x000055e9517b4948 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55e955612d08, put_in_cache=put_in_cache@entry=true) at /test/bb-10.10-MDEV-28883_dbg/sql/sql_connect.cc:1418
 
#23 0x000055e9517b4e51 in handle_one_connection (arg=0x55e955612d08) at /test/bb-10.10-MDEV-28883_dbg/sql/sql_connect.cc:1312
 
#24 0x00001490c60fb609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 
#25 0x00001490c5ce7133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

marko FYI

 Comments   
Comment by Roel Van de Paar [ 2022-07-21 ]

Also tested this bug against the updated bb-10.10-MDEV-28883 branch (which received a patch for MDEV-28965), and the bug remains present.

Comment by Marko Mäkelä [ 2022-07-26 ]

Roel, can you please test this with a main branch, 10.6 or later? This does not necessarily look related to MDEV-28883.

Comment by Elena Stepanova [ 2022-07-26 ]

As said elsewhere, it is very likely to be MDEV-28950.

Comment by Igor Babaev [ 2022-07-26 ]

Built bb-10.10-MDEV-28883 without my commits: still observed the same bug.
The full test case that I tried in mtr looks like this:

--source include/have_innodb.inc
 
SET sql_mode='';
 
CREATE TABLE t (c1 INT, c2 CHAR(255)) ENGINE=InnoDB;
 
INSERT INTO t VALUES (0,'a');
 
ALTER TABLE t KEY_BLOCK_SIZE=2;
 
INSERT INTO t VALUES (1,'b'),(2,'c'),(3,'c');
 
SET @save_innodb_compression_level= @@innodb_compression_level;
 
SET GLOBAL innodb_compression_level=0;
 
INSERT INTO t VALUES (4,'d'),(5,'e'),(6,'f');
 
INSERT INTO t VALUES (7,'e');
 
SET GLOBAL innodb_compression_level= @save_innodb_compression_level;
 
SET sql_mode=default; 
DROP TABLE t;

Comment by Roel Van de Paar [ 2022-07-26 ]

marko Thank you. Not present in main branches 10.3 to 10.10 (all tested, dbg+opt).
elenst Thank you. Indeed, this could be the case.
igor Thank you for confirming.

Checked that bb-10.10-MDEV-28883 is 54 commits behind, and that MDEV-28950 patch is part of the list: it is; marking this as a duplicate of MDEV-28950.

Comment by Marko Mäkelä [ 2022-07-27 ]

I verified this as a duplicate of MDEV-28950 and will add an even simpler version of the test case that would trigger the assertion failure with all 3 innodb_page_size combinations of the test when the fix is not present.

Generated at Thu Feb 08 10:05:07 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.