Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-14066

[Draft] Assertion failed: rec_get_deleted_flag(rec, dict_table_is_comp(cursor->index->table))

Details

    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

      Attachments

        1. master.log
          234 kB
          Elena Stepanova
        2. trial3.log
          143 kB
          Elena Stepanova

        Issue Links

          Activity

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

            marko Marko Mäkelä added a comment - The delete-mark mismatch is something that I would associate with the upstream bug that is reported as MDEV-9663 .
            midenok Aleksey Midenkov added a comment - - edited

            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
            

            midenok Aleksey Midenkov added a comment - - edited 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

            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.

            marko Marko Mäkelä added a comment - 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 .

            People

              elenst Elena Stepanova
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.