[MDEV-14066] [Draft] Assertion failed: rec_get_deleted_flag(rec, dict_table_is_comp(cursor->index->table)) Created: 2017-10-14  Updated: 2021-11-03  Resolved: 2021-11-03

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

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

Attachments: File master.log     File trial3.log    
Issue Links:
Duplicate
duplicates MDEV-14097 [Draft] Assertion `rec_get_deleted_fl... Closed
is duplicated by MDEV-14097 [Draft] Assertion `rec_get_deleted_fl... Closed
Relates
relates to MDEV-9663 InnoDB assertion failure: *cursor->in... Closed
relates to MDEV-18706 ER_LOCK_DEADLOCK on concurrent read a... Stalled

 Description   

10.3 f3ad3bbe7704d2a45e825b763d9ca36e3a7b4483

Assertion failed: rec_get_deleted_flag(rec, dict_table_is_comp(cursor->index->table)), file D:\qa-win-debug\build\storage\innobase\row\row0ins.cc, line 349
171012 18:12:56 [ERROR] mysqld got exception 0x80000003 ;
 
mysqld.exe!my_sigabrt_handler()[my_thr_init.c:488]
mysqld.exe!raise()[signal.cpp:516]
mysqld.exe!abort()[abort.cpp:71]
mysqld.exe!common_assert_to_stderr<wchar_t>()[assert.cpp:149]
mysqld.exe!_wassert()[assert.cpp:404]
mysqld.exe!row_ins_clust_index_entry_by_modify()[row0ins.cc:348]
mysqld.exe!row_ins_clust_index_entry_low()[row0ins.cc:2725]
mysqld.exe!row_ins_clust_index_entry()[row0ins.cc:3242]
mysqld.exe!row_ins_index_entry()[row0ins.cc:3359]
mysqld.exe!row_ins_index_entry_step()[row0ins.cc:3509]
mysqld.exe!row_ins()[row0ins.cc:3651]
mysqld.exe!row_ins_step()[row0ins.cc:3855]
mysqld.exe!row_insert_for_mysql()[row0mysql.cc:1491]
mysqld.exe!ha_innobase::write_row()[ha_innodb.cc:8347]
mysqld.exe!handler::ha_write_row()[handler.cc:6022]
mysqld.exe!write_record()[sql_insert.cc:1929]
mysqld.exe!mysql_insert()[sql_insert.cc:1057]
mysqld.exe!mysql_execute_command()[sql_parse.cc:4682]
mysqld.exe!mysql_parse()[sql_parse.cc:7921]
mysqld.exe!dispatch_command()[sql_parse.cc:1821]
mysqld.exe!do_command()[sql_parse.cc:1369]
mysqld.exe!threadpool_process_request()[threadpool_common.cc:366]
mysqld.exe!tp_callback()[threadpool_common.cc:192]
mysqld.exe!tp_callback()[threadpool_win.cc:378]
mysqld.exe!io_completion_callback()[threadpool_win.cc:395]
KERNEL32.DLL!VirtualUnlock()
ntdll.dll!RtlGetActiveActivationContext()
ntdll.dll!RtlFreeUnicodeString()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0xe6084a2660): INSERT INTO t1 (col1,col2,col3,col4) VALUES /* NULL */ (NULL,NULL,NULL,REPEAT(CAST(NULL AS CHAR(1)),@fill_amount)), (NULL,NULL,NULL,REPEAT(CAST(NULL AS CHAR(1)),@fill_amount))  /* QNO 365 CON_ID 21 */
Connection ID (thread ID): 21
Status: NOT_KILLED

http://buildbot.askmonty.org/buildbot/builders/qa-win-debug/builds/644/steps/crash_tests/logs/stdio

E:\buildbot\rqg/runall.pl --no-mask --seed=1507821092 --threads=5 --duration=400 --queries=100M --reporters=QueryTimeout,Backtrace,ErrorLog,Deadlock,Shutdown --redefine=conf/mariadb/redefine_random_keys.yy --redefine=conf/mariadb/redefine_set_session_vars.yy --validators=TransformerNoComparator --transformers=ConvertSubqueriesToViews,DisableOptimizations,EnableOptimizations,ExecuteAsCTE,ExecuteAsInsertSelect,ExecuteAsPreparedOnce,ExecuteAsSelectItem,ExecuteAsUnion,ExecuteAsUpdateDelete,ExecuteAsView,NullIf,OrderBy,StraightJoin,ExecuteAsExecuteImmediate --grammar=conf/runtime/alter_online.yy --gendata=conf/runtime/alter_online.zz --mtr-build-thread=150 --basedir1=D:\qa-win-debug\build --vardir1=E:\buildbot\vardirs\qa-win-debug\10.3-644\optim-crash-tests/current1_1

Not reproducible easily



 Comments   
Comment by Marko Mäkelä [ 2018-04-07 ]

The delete-mark mismatch is something that I would associate with the upstream bug that is reported as MDEV-9663.

Comment by Aleksey Midenkov [ 2021-07-12 ]

bb-10.6-midenok-MDEV-18706 reproduces similar failure via rollback:

#3  0x000032ba1604ef36 in __GI___assert_fail (assertion=0x560a08b36880 "rec_get_deleted_flag(btr_pcur_get_rec(pcur), (node->table)->not_redundant())", file=0x560a08b35d20 "/data/Server/bb-10.6-midenok-MDEV-18706/storage/innobase/row/row0umod.cc", line=385, function=0x560a08b364a0 "dberr_t row_undo_mod_clust(undo_node_t*, que_thr_t*)") at assert.c:101
#4  0x0000560a07afa56a in row_undo_mod_clust (node=0x61a0003ca908, thr=0x61600711bbc0) at /data/Server/bb-10.6-midenok-MDEV-18706/storage/innobase/row/row0umod.cc:385
#5  0x0000560a07b00f65 in row_undo_mod (node=0x61a0003ca908, thr=0x61600711bbc0) at /data/Server/bb-10.6-midenok-MDEV-18706/storage/innobase/row/row0umod.cc:1408
#6  0x0000560a0774072b in row_undo (node=0x61a0003ca908, thr=0x61600711bbc0) at /data/Server/bb-10.6-midenok-MDEV-18706/storage/innobase/row/row0undo.cc:444
#7  0x0000560a07740c1a in row_undo_step (thr=0x61600711bbc0) at /data/Server/bb-10.6-midenok-MDEV-18706/storage/innobase/row/row0undo.cc:496
#8  0x0000560a075eac84 in que_thr_step (thr=0x61600711bbc0) at /data/Server/bb-10.6-midenok-MDEV-18706/storage/innobase/que/que0que.cc:651
#9  0x0000560a075eb048 in que_run_threads_low (thr=0x61600711bbc0) at /data/Server/bb-10.6-midenok-MDEV-18706/storage/innobase/que/que0que.cc:709
#10 0x0000560a075eb1ea in que_run_threads (thr=0x61600711bbc0) at /data/Server/bb-10.6-midenok-MDEV-18706/storage/innobase/que/que0que.cc:729
#11 0x0000560a077ddebb in trx_t::rollback_low (this=0x76f1193aeb68, savept=0x0) at /data/Server/bb-10.6-midenok-MDEV-18706/storage/innobase/trx/trx0roll.cc:131
#12 0x0000560a077d82a2 in trx_rollback_for_mysql_low (trx=0x76f1193aeb68) at /data/Server/bb-10.6-midenok-MDEV-18706/storage/innobase/trx/trx0roll.cc:196
#13 0x0000560a077d88b4 in trx_rollback_for_mysql (trx=0x76f1193aeb68) at /data/Server/bb-10.6-midenok-MDEV-18706/storage/innobase/trx/trx0roll.cc:227
#14 0x0000560a0732993f in innobase_rollback (hton=0x615000002b18, thd=0x62b0000bd218, rollback_trx=false) at /data/Server/bb-10.6-midenok-MDEV-18706/storage/innobase/handler/ha_innodb.cc:4560
#15 0x0000560a06a1acfc in ha_rollback_trans (thd=0x62b0000bd218, all=false) at /data/Server/bb-10.6-midenok-MDEV-18706/sql/handler.cc:2153
#16 0x0000560a066a2a6e in trans_rollback_stmt (thd=0x62b0000bd218) at /data/Server/bb-10.6-midenok-MDEV-18706/sql/transaction.cc:535
#17 0x0000560a06288419 in mysql_execute_command (thd=0x62b0000bd218, is_called_from_prepared_stmt=false) at /data/Server/bb-10.6-midenok-MDEV-18706/sql/sql_parse.cc:6048
#18 0x0000560a062940ce in mysql_parse (thd=0x62b0000bd218, rawbuf=0x62b0000c4238 "INSERT INTO t1 (a) VALUES ( 1), ( 382) /* E_R Thread2 QNO 3792 CON_ID 15 */", length=75, parser_state=0x208e3c517b20) at /data/Server/bb-10.6-midenok-MDEV-18706/sql/sql_parse.cc:8028

Comment by Marko Mäkelä [ 2021-09-29 ]

Failures in locking-related development branches could be due to some changes that break locking. This assertion is only reporting an inconsistency that must have been caused earlier during the execution. The culprit is always somewhere else. In particular, during the time any ROLLBACK is executed (even a rollback of a single row), the transaction must already hold exclusive locks on the records that it is deleting or updating. If that is not the case due to some ‘locking optimization’, then it could happen that another transaction may modify the record before rollback is executed. In such a case, I would expect the DB_TRX_ID of the clustered index record not to match the trx_t::id.

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