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

Assertion `lock_table_has(trx, table, LOCK_IX)' failed in lock_trx_has_expl_x_lock

    XMLWordPrintable

    Details

      Description

      The assertion is in a different function comparing to MDEV-29118. I suppose depending on the root cause it may or may not be a duplicate, I'll leave it to the fixer to determine.

      The test case is non-deterministic by nature, although it fails every time for me. If it doesn't fail for you right away, try to increase the number of rows read from the sequence table (seq_1_to_X) or run with --repeat. The failure is rr-able, but it may require several attempts.

      --source include/have_innodb.inc
      --source include/have_sequence.inc
       
      CREATE TABLE t1 (pk INT PRIMARY KEY, f1 VARCHAR(1)) ENGINE=InnoDB;
      INSERT INTO t1 (pk) VALUES (1);
       
      CREATE TABLE t2 (pk INT PRIMARY KEY) ENGINE=InnoDB;
      INSERT INTO t2 VALUES (1);
       
      CREATE TABLE t3 (pk INT PRIMARY KEY, f3 VARCHAR(1), KEY (f3)) ENGINE=InnoDB;
      INSERT INTO t3 SELECT seq, CHR(seq%26+97) FROM seq_1_to_100;
       
      --connect (con1,localhost,root,,test)
      --send
      DELETE t1.* FROM t1 WHERE f1 NOT IN (SELECT t3.f3 FROM t2 JOIN t3);
       
      --connection default
      START TRANSACTION;
      UPDATE t3 SET f3 = 'a';
      UPDATE t1 SET f1 = 'z';
       
      # Cleanup
      COMMIT;
      --connection con1
      --reap
      --disconnect con1
      --connection default
      DROP TABLE t1, t2, t3;
      

      10.3 32bab2ce

      mysqld: /data/src/10.3/storage/innobase/lock/lock0lock.cc:6539: bool lock_trx_has_expl_x_lock(const trx_t*, const dict_table_t*, const buf_block_t*, ulint): Assertion `lock_table_has(trx, table, LOCK_IX)' failed.
      220917 17:21:25 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007fb03fc0d662 in __GI___assert_fail (assertion=0x559fe6de6e80 "lock_table_has(trx, table, LOCK_IX)", file=0x559fe6dde1e0 "/data/src/10.3/storage/innobase/lock/lock0lock.cc", line=6539, function=0x559fe6de6e00 "bool lock_trx_has_expl_x_lock(const trx_t*, const dict_table_t*, const buf_block_t*, ulint)") at assert.c:101
      #8  0x0000559fe5b4cdd9 in lock_trx_has_expl_x_lock (trx=0x7fb03626d968, table=0x6190000dda08, block=0x7fb0359b3cc0, heap_no=2) at /data/src/10.3/storage/innobase/lock/lock0lock.cc:6539
      #9  0x0000559fe5debad2 in row_upd_clust_step (node=0x620000011c08, thr=0x6240001e2188) at /data/src/10.3/storage/innobase/row/row0upd.cc:3175
      #10 0x0000559fe5dec9bd in row_upd (node=0x620000011c08, thr=0x6240001e2188) at /data/src/10.3/storage/innobase/row/row0upd.cc:3304
      #11 0x0000559fe5ded92f in row_upd_step (thr=0x6240001e2188) at /data/src/10.3/storage/innobase/row/row0upd.cc:3448
      #12 0x0000559fe5d18193 in row_update_for_mysql (prebuilt=0x620000011108) at /data/src/10.3/storage/innobase/row/row0mysql.cc:1827
      #13 0x0000559fe59e83de in ha_innobase::delete_row (this=0x61d000215310, record=0x6190000e0220 "\377\001") at /data/src/10.3/storage/innobase/handler/ha_innodb.cc:9090
      #14 0x0000559fe549d534 in handler::ha_delete_row (this=0x61d000215310, buf=0x6190000e0220 "\377\001") at /data/src/10.3/sql/handler.cc:6583
      #15 0x0000559fe58b574e in TABLE::delete_row (this=0x61f0000524f0) at /data/src/10.3/sql/sql_delete.cc:245
      #16 0x0000559fe58b2543 in multi_delete::send_data (this=0x62b0000428e8, values=...) at /data/src/10.3/sql/sql_delete.cc:1244
      #17 0x0000559fe4e541f8 in end_send (join=0x62b000042960, join_tab=0x62d00019a820, end_of_records=false) at /data/src/10.3/sql/sql_select.cc:21118
      #18 0x0000559fe4e4c7f0 in evaluate_join_record (join=0x62b000042960, join_tab=0x62d00019a490, error=0) at /data/src/10.3/sql/sql_select.cc:20159
      #19 0x0000559fe4e4b139 in sub_select (join=0x62b000042960, join_tab=0x62d00019a490, end_of_records=false) at /data/src/10.3/sql/sql_select.cc:19932
      #20 0x0000559fe4e49186 in do_select (join=0x62b000042960, procedure=0x0) at /data/src/10.3/sql/sql_select.cc:19470
      #21 0x0000559fe4ddd226 in JOIN::exec_inner (this=0x62b000042960) at /data/src/10.3/sql/sql_select.cc:4171
      #22 0x0000559fe4ddabf7 in JOIN::exec (this=0x62b000042960) at /data/src/10.3/sql/sql_select.cc:3965
      #23 0x0000559fe4dde559 in mysql_select (thd=0x62a0000c0270, tables=0x62b00003fab8, wild_num=0, fields=..., conds=0x62b0000426f8, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3489926016, result=0x62b0000428e8, unit=0x62a0000c4120, select_lex=0x62a0000c48b8) at /data/src/10.3/sql/sql_select.cc:4374
      #24 0x0000559fe4d1e12c in mysql_execute_command (thd=0x62a0000c0270) at /data/src/10.3/sql/sql_parse.cc:4767
      #25 0x0000559fe4d335fc in mysql_parse (thd=0x62a0000c0270, rawbuf=0x62b00003f290 "DELETE t1.* FROM t1 WHERE f1 NOT IN (SELECT t3.f3 FROM t2 JOIN t3)", length=66, parser_state=0x7fb0293f3a00, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:7871
      #26 0x0000559fe4d0aba2 in dispatch_command (command=COM_QUERY, thd=0x62a0000c0270, packet=0x629000140271 "DELETE t1.* FROM t1 WHERE f1 NOT IN (SELECT t3.f3 FROM t2 JOIN t3)", packet_length=66, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1852
      #27 0x0000559fe4d0777e in do_command (thd=0x62a0000c0270) at /data/src/10.3/sql/sql_parse.cc:1398
      #28 0x0000559fe50c8eb6 in do_handle_one_connection (connect=0x611000041e70) at /data/src/10.3/sql/sql_connect.cc:1403
      #29 0x0000559fe50c87b2 in handle_one_connection (arg=0x611000041e70) at /data/src/10.3/sql/sql_connect.cc:1308
      #30 0x0000559fe66737d1 in pfs_spawn_thread (arg=0x61600000edf0) at /data/src/10.3/storage/perfschema/pfs.cc:1869
      #31 0x00007fb03fda6ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #32 0x00007fb03fcd6def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      Reproducible the same way on all of 10.3-10.10.
      No obvious problem on a non-debug build.

        Attachments

          Activity

            People

            Assignee:
            vlad.lesin Vladislav Lesin
            Reporter:
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:

                Git Integration

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