[MDEV-18505] InnoDB: Failing assertion: pos != ULINT_UNDEFINED in row_build_row_ref_in_tuple upon DML after dropping columns Created: 2019-02-07  Updated: 2019-04-01  Resolved: 2019-04-01

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Storage Engine - InnoDB
Affects Version/s: 10.4
Fix Version/s: 10.4.4

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None


 Description   

Note: With the test case below, the failure only happens for me on non-debug builds (RelWithDebInfo, with and without ASAN, different revisions). However, it has been seen before in a concurrent test on a debug/gcov build as well, the stack trace from it is at the end of the description.

--source include/have_innodb.inc
 
 
 
SET FOREIGN_KEY_CHECKS= OFF;
 
 
 
CREATE TABLE t1 (
 
  pk INT AUTO_INCREMENT,
 
  a VARCHAR(8),
 
  b VARCHAR(8),
 
  i TINYINT,
 
  PRIMARY KEY (pk),
 
  UNIQUE (b)
 
) ENGINE=InnoDB;
 
 
 
INSERT INTO t1 (a,b,i) VALUES
 
(NULL,'b',NULL),('s',NULL,1),('h','o',8),('q','n',NULL);
 
 
 
ALTER TABLE t1 ADD FOREIGN KEY (b) REFERENCES tx (f);
 
--error ER_FK_COLUMN_CANNOT_DROP
 
ALTER TABLE t1 DROP COLUMN b;
 
ALTER TABLE t1 DROP COLUMN a;
 
REPLACE INTO t1 (i) VALUES (-18);
 
 
 
# Cleanup
 
DROP TABLE t1;

10.4 RelWithDebInfo bb970dda

 
2019-02-26 22:15:16 0x7f512c094700  InnoDB: Assertion failure in file /data/src/10.4/storage/innobase/row/row0row.cc line 1144
 
InnoDB: Failing assertion: pos != ULINT_UNDEFINED
 
 
 
#4  0x00007f51319233fa in abort () from /lib/x86_64-linux-gnu/libc.so.6
 
#5  0x000055c54d3126f4 in ut_dbg_assertion_failed (expr=expr@entry=0x55c54dccc5a0 "pos != ULINT_UNDEFINED", file=file@entry=0x55c54dccc4f0 "/data/src/10.4/storage/innobase/row/row0row.cc", line=line@entry=1144) at /data/src/10.4/storage/innobase/ut/ut0dbg.cc:60
 
#6  0x000055c54d8e9788 in row_build_row_ref_in_tuple (ref=0x7f50d8047e30, rec=0x7f51270e408a <error: Cannot access memory at address 0x7f51270e408a>, rec@entry=0x21010000750001 <error: Cannot access memory at address 0x21010000750001>, index=index@entry=0x7f50d8083590, offsets=0x7f512c08faa0) at /data/src/10.4/storage/innobase/row/row0row.cc:1144
 
#7  0x000055c54d8eeadc in row_sel_get_clust_rec_for_mysql (mtr=0x7f512c0900e8, vrow=0x55c54ed70c78 <srv_page_size>, offset_heap=0x0, offsets=0x7f512c08f218, out_rec=<synthetic pointer>, thr=0x7f51270e408a, rec=0x21010000750001 <error: Cannot access memory at address 0x21010000750001>, sec_index=0x7f50d8083590, prebuilt=0x7f50d8047910) at /data/src/10.4/storage/innobase/row/row0sel.cc:3247
 
#8  row_search_mvcc (buf=buf@entry=0x7f50d8089a08 "", mode=PAGE_CUR_UNSUPP, mode@entry=PAGE_CUR_GE, prebuilt=<optimized out>, match_mode=match_mode@entry=1, direction=direction@entry=0) at /data/src/10.4/storage/innobase/row/row0sel.cc:5247
 
#9  0x000055c54d81cbb5 in ha_innobase::index_read (this=0x7f50d808a400, buf=0x7f50d8089a08 "", key_ptr=<optimized out>, key_len=<optimized out>, find_flag=<optimized out>) at /data/src/10.4/storage/innobase/handler/ha_innodb.cc:9314
 
#10 0x000055c54d5f9cd3 in handler::index_read_idx_map (this=0x7f50d808a400, buf=0x7f50d8089a08 "", index=1, key=0x7f512c090700 "\001\a\t,Q\177", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at /data/src/10.4/sql/handler.cc:6015
 
#11 0x000055c54d5fff09 in handler::ha_index_read_idx_map (this=0x7f50d808a400, buf=0x7f50d8089a08 "", index=index@entry=1, key=key@entry=0x7f512c090700 "\001\a\t,Q\177", keypart_map=1, find_flag=find_flag@entry=HA_READ_KEY_EXACT) at /data/src/10.4/sql/handler.cc:3067
 
#12 0x000055c54d3c6eeb in write_record (thd=thd@entry=0x7f50d80009a8, table=table@entry=0x7f50d80ca608, info=info@entry=0x7f512c0908a0) at /data/src/10.4/sql/sql_insert.cc:1775
 
#13 0x000055c54d3cd8d8 in mysql_insert (thd=thd@entry=0x7f50d80009a8, table_list=<optimized out>, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_REPLACE, ignore=false) at /data/src/10.4/sql/sql_insert.cc:1067
 
#14 0x000055c54d3fc026 in mysql_execute_command (thd=thd@entry=0x7f50d80009a8) at /data/src/10.4/sql/sql_parse.cc:4791
 
#15 0x000055c54d400211 in mysql_parse (thd=thd@entry=0x7f50d80009a8, rawbuf=<optimized out>, length=32, parser_state=parser_state@entry=0x7f512c0931d0, 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:8157
 
#16 0x000055c54d402a3f in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7f50d80009a8, packet=packet@entry=0x7f50d8009b39 "REPLACE INTO t1 (i) VALUES (-18)", packet_length=packet_length@entry=32, 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:1829
 
#17 0x000055c54d403e97 in do_command (thd=0x7f50d80009a8) at /data/src/10.4/sql/sql_parse.cc:1358
 
#18 0x000055c54d4de37c in do_handle_one_connection (connect=connect@entry=0x55c550bd3338) at /data/src/10.4/sql/sql_connect.cc:1399
 
#19 0x000055c54d4de4e4 in handle_one_connection (arg=arg@entry=0x55c550bd3338) at /data/src/10.4/sql/sql_connect.cc:1302
 
#20 0x000055c54d7fbd34 in pfs_spawn_thread (arg=0x55c550bd3398) at /data/src/10.4/storage/perfschema/pfs.cc:1862
 
#21 0x00007f51335f1494 in start_thread (arg=0x7f512c094700) at pthread_create.c:333
 
#22 0x00007f51319d793f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Not reproducible on 10.3.

10.4 e80bcd7f GCOV

 
2019-02-06 17:07:06 0x7f30a5636700  InnoDB: Assertion failure in file /home/vsts/server/storage/innobase/row/row0row.cc line 1144
 
InnoDB: Failing assertion: pos != ULINT_UNDEFINED
 
 
 
#1  0x00007f30bce1802a in __GI_abort () at abort.c:89
 
#2  0x0000556d9a3f5650 in ut_dbg_assertion_failed (expr=expr@entry=0x556d9ad446f8 "pos != ULINT_UNDEFINED", file=file@entry=0x556d9ad44640 "/home/vsts/server/storage/innobase/row/row0row.cc", line=line@entry=1144) at /home/vsts/server/storage/innobase/ut/ut0dbg.cc:60
 
#3  0x0000556d9a8ebd98 in row_build_row_ref_in_tuple (ref=0x7f30780c9778, rec=0x7f309d86a8be <error: Cannot access memory at address 0x7f309d86a8be>, rec@entry=0x100 <error: Cannot access memory at address 0x100>, index=index@entry=0x7f3088062980, offsets=0x7f30a56c6030) at /home/vsts/server/storage/innobase/row/row0row.cc:1144
 
#4  0x0000556d9a8f3b95 in row_sel_get_clust_rec_for_mysql (mtr=0x7f30a56c6f78, vrow=0x556d9b5be700 <srv_page_size>, offset_heap=0x28be, offsets=0x7f30a56c5ff0, out_rec=<synthetic pointer>, thr=0x7f30a56c5f78, rec=0x100 <error: Cannot access memory at address 0x100>, sec_index=0x7f3088062980, prebuilt=0x7f30780c9130) at /home/vsts/server/storage/innobase/row/row0sel.cc:3247
 
#5  row_search_mvcc (buf=buf@entry=0x7f30780e6458 <incomplete sequence \353>, mode=PAGE_CUR_UNSUPP, mode@entry=PAGE_CUR_G, prebuilt=0x7f30780c9130, match_mode=match_mode@entry=0, direction=direction@entry=0) at /home/vsts/server/storage/innobase/row/row0sel.cc:5234
 
#6  0x0000556d9a82862b in ha_innobase::index_read (this=0x7f307811b030, buf=0x7f30780e6458 <incomplete sequence \353>, key_ptr=<optimized out>, key_len=0, find_flag=<optimized out>) at /home/vsts/server/storage/innobase/handler/ha_innodb.cc:9283
 
#7  0x0000556d9a8116f7 in ha_innobase::index_first (this=<optimized out>, buf=<optimized out>) at /home/vsts/server/storage/innobase/handler/ha_innodb.cc:9659
 
#8  0x0000556d9a6b1be7 in handler::ha_index_first (this=0x7f307811b030, buf=0x7f30780e6458 <incomplete sequence \353>) at /home/vsts/server/sql/handler.cc:3126
 
#9  0x0000556d9a507f00 in join_read_first (tab=0x7f3078156418) at /home/vsts/server/sql/sql_select.cc:20389
 
#10 0x0000556d9a4fe6e5 in sub_select (join=0x7f3078191ed8, join_tab=0x7f3078156418, end_of_records=<optimized out>) at /home/vsts/server/sql/sql_select.cc:19387
 
#11 0x0000556d9a51ca56 in do_select (procedure=<optimized out>, join=0x7f3078191ed8) at /home/vsts/server/sql/sql_select.cc:18930
 
#12 JOIN::exec_inner (this=this@entry=0x7f3078191ed8) at /home/vsts/server/sql/sql_select.cc:4094
 
#13 0x0000556d9a51cc79 in JOIN::exec (this=this@entry=0x7f3078191ed8) at /home/vsts/server/sql/sql_select.cc:3888
 
#14 0x0000556d9a51cdc2 in mysql_select (thd=thd@entry=0x7f3078000bb8, tables=0x7f3078013808, wild_num=<optimized out>, fields=..., conds=0x7f3078015318, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2214857472, result=0x7f3078191eb0, unit=0x7f30780048b8, select_lex=0x7f3078011ef8) at /home/vsts/server/sql/sql_select.cc:4293
 
#15 0x0000556d9a51d71e in handle_select (thd=thd@entry=0x7f3078000bb8, lex=lex@entry=0x7f30780047f0, result=result@entry=0x7f3078191eb0, setup_tables_done_option=setup_tables_done_option@entry=0) at /home/vsts/server/sql/sql_select.cc:385
 
#16 0x0000556d9a3e8e1e in execute_sqlcom_select (thd=thd@entry=0x7f3078000bb8, all_tables=0x7f3078013808) at /home/vsts/server/sql/sql_parse.cc:6567
 
#17 0x0000556d9a4cfa6b in mysql_execute_command (thd=thd@entry=0x7f3078000bb8) at /home/vsts/server/sql/sql_parse.cc:3804
 
#18 0x0000556d9a4d1a39 in mysql_parse (thd=thd@entry=0x7f3078000bb8, rawbuf=<optimized out>, length=145, parser_state=parser_state@entry=0x7f30a56c9280, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /home/vsts/server/sql/sql_parse.cc:8120
 
#19 0x0000556d9a4d36a9 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7f3078000bb8, packet=packet@entry=0x7f3078009a89 "", packet_length=packet_length@entry=146, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /home/vsts/server/sql/sql_parse.cc:1806
 
#20 0x0000556d9a4d5219 in do_command (thd=0x7f3078000bb8) at /home/vsts/server/sql/sql_parse.cc:1356
 
#21 0x0000556d9a59a904 in do_handle_one_connection (connect=connect@entry=0x556d9da62bc8) at /home/vsts/server/sql/sql_connect.cc:1399
 
#22 0x0000556d9a59aa24 in handle_one_connection (arg=0x556d9da62bc8) at /home/vsts/server/sql/sql_connect.cc:1302
 
#23 0x00007f30bdc576ba in start_thread (arg=0x7f30a56ca700) at pthread_create.c:333
 
#24 0x00007f30bcee841d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109



 Comments   
Comment by Marko Mäkelä [ 2019-04-01 ]

I am unable to reproduce this bug. Maybe something related to FOREIGN KEY or MDL was recently fixed outside InnoDB? There have been some fixes to InnoDB ALTER TABLE error handling since this bug was filed, but I cannot point out anything that would clearly affect this test.

I would assume that the error is somehow related to the rejected DROP COLUMN b. Apparently, the table contains two indexes: pk and b, and in the stack trace from the gcov build, it appears that the REPLACE is accessing the unique index b.

Comment by Elena Stepanova [ 2019-04-01 ]

The failure disappeared after this merge

commit 2a791c53ad93c8bc1441dd227000234bd49c4990
 
Merge: b5c72a8 723ffdb
 
Author: Marko Mäkelä <marko.makela@mariadb.com>
 
Date:   Wed Mar 6 09:00:52 2019 +0200
 
 
 
    Merge 10.3 into 10.4

Which part of it fixed it, is hard for me to say, since it wasn't reproducible on earlier versions.

marko, Unless you want to dig further to find out the exact change, I'm going to close it.

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