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

Unexpected ER_CRASHED_ON_USAGE and Assertion `limit >= trx_id' failed in purge_node_t::skip

Details

    Description

      Notes:

      • In the test case below, the last ALTER returns ER_CRASHED_ON_USAGE. There is no good reason for this. It is masked in the test case so that we can get to the assertion failure as was requested. I am not sure whether the assertion failure and the corruption are the same bug; maybe the corruption needs to be filed separately.
      • I could only reproduce the assertion failure on 10.4. It currently happens very reliably for me on 10.4, but it's still a non-deterministic test case, run with --repeat if it doesn't fail. Probably it can be made deterministic with help of InnoDB debug injections (or even debug variables). The corruption errors are reproducible on 10.4+, although much older versions of 10.4; but not on 10.3.
      • Shutdown isn't needed for the failure to happen. I added it in the pursuit of better reproducibility.

      --source include/have_innodb.inc
      		 
      --source include/have_partition.inc
      		 
      --source include/have_sequence.inc
      		 
       
      		 
      call mtr.add_suppression("is marked as crashed and should be repaired");
      		 
      call mtr.add_suppression("user defined columns in InnoDB, but");
      		 
       
      		 
      CREATE TABLE t1 (a INT, UNIQUE USING HASH (a)) ENGINE=InnoDB
      		 
      PARTITION BY RANGE(a) (
      		 
        PARTITION p1 VALUES LESS THAN (2),
      		 
        PARTITION p2 VALUES LESS THAN (101)
      		 
      );
      		 
      INSERT INTO t1 SELECT seq FROM seq_1_to_100;
      		 
       
      		 
      ALTER TABLE t1 ADD PARTITION (PARTITION p3 VALUES LESS THAN (MAXVALUE));
      		 
       
      		 
      --error ER_CRASHED_ON_USAGE
      		 
      ALTER TABLE t1 FORCE;
      		 
       
      		 
      --source include/restart_mysqld.inc
      		 
       
      		 
      DROP TABLE t1;

      10.4 b2bb747f

      		 
      2021-05-11 19:32:02 9 [Warning] InnoDB: Table test/t1#P#p1 contains 2 user defined columns in InnoDB, but 1 columns in MariaDB. Please check INFORMATION_SCHEMA.INNODB_SYS_COLUMNS and https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/ for how to resolve the issue.
      		 
      2021-05-11 19:32:02 9 [ERROR] mysqld: Table 't1' is marked as crashed and should be repaired
      		 
      2021-05-11 19:32:02 0 [Note] /mnt-hd8t/bld/10.4-debug-nightly/bin/mysqld (initiated by: root[root] @ localhost []): Normal shutdown
      		 
      2021-05-11 19:32:02 0 [Note] InnoDB: FTS optimize thread exiting.
      		 
      2021-05-11 19:32:02 0 [Note] Event Scheduler: Purging the queue. 0 events
      		 
      mysqld: /data/src/10.4/storage/innobase/include/row0purge.h:175: void purge_node_t::skip(table_id_t, trx_id_t): Assertion `limit >= trx_id' failed.
      		 
      210511 19:32:02 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      #7  0x00007f4593444f36 in __GI___assert_fail (assertion=0x563c26a90b5e "limit >= trx_id", file=0x563c26a90b70 "/data/src/10.4/storage/innobase/include/row0purge.h", line=175, function=0x563c26a90ba8 "void purge_node_t::skip(table_id_t, trx_id_t)") at assert.c:101
      		 
      #8  0x0000563c262a1d84 in purge_node_t::skip (this=0x563c29ba9250, id=20, limit=33) at /data/src/10.4/storage/innobase/include/row0purge.h:175
      		 
      #9  0x0000563c262a03a7 in row_purge_parse_undo_rec (node=0x563c29ba9250, undo_rec=0x563c29ba97f0 "", updated_extern=0x7f456f7fdcfe, thr=0x563c29ba9080) at /data/src/10.4/storage/innobase/row/row0purge.cc:1134
      		 
      #10 0x0000563c262a0ad1 in row_purge (node=0x563c29ba9250, undo_rec=0x563c29ba97f0 "", thr=0x563c29ba9080) at /data/src/10.4/storage/innobase/row/row0purge.cc:1261
      		 
      #11 0x0000563c262a0e9c in row_purge_step (thr=0x563c29ba9080) at /data/src/10.4/storage/innobase/row/row0purge.cc:1342
      		 
      #12 0x0000563c26209504 in que_thr_step (thr=0x563c29ba9080) at /data/src/10.4/storage/innobase/que/que0que.cc:1038
      		 
      #13 0x0000563c2620979c in que_run_threads_low (thr=0x563c29ba9080) at /data/src/10.4/storage/innobase/que/que0que.cc:1100
      		 
      #14 0x0000563c26209a02 in que_run_threads (thr=0x563c29ba9080) at /data/src/10.4/storage/innobase/que/que0que.cc:1140
      		 
      #15 0x0000563c262eafcc in srv_task_execute (slot=0x563c270b5ec0 <srv_sys+832>) at /data/src/10.4/storage/innobase/srv/srv0srv.cc:2465
      		 
      #16 0x0000563c262eb261 in srv_worker_thread (arg=0x0) at /data/src/10.4/storage/innobase/srv/srv0srv.cc:2520
      		 
      #17 0x00007f459395c609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      		 
      #18 0x00007f4593530293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

      Attachments

        Issue Links

          blocks

          Bug - A problem which impairs or prevents the functions of the product. MDEV-35612 EXCHANGE PARTITION does not work for tables with unique blobs

          • Major - Major loss of function.
          • Closed
          is caused by

          Task - A task that needs to be done. MDEV-371 Unique indexes for blobs

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            I cannot reproduce the InnoDB purge assertion on the current 10.6 ccb7a1e9a15e6a47aba97f9bdbfab2e4bf64c447.

            The corruption goes away if I remove the USING HASH. There would seem to be something wrong with MDEV-371, because I see that the SQL layer is defining a hidden virtual column DB_ROW_HASH_1.

            marko Marko Mäkelä added a comment - I cannot reproduce the InnoDB purge assertion on the current 10.6 ccb7a1e9a15e6a47aba97f9bdbfab2e4bf64c447. The corruption goes away if I remove the USING HASH . There would seem to be something wrong with MDEV-371 , because I see that the SQL layer is defining a hidden virtual column DB_ROW_HASH_1 .
            Roel Roel Van de Paar added a comment - 

            --source include/have_innodb.inc
            		 
            --source include/have_partition.inc
            		 
             
            		 
            CREATE TABLE t (c INT, UNIQUE USING HASH (c)) ENGINE=InnoDB PARTITION BY HASH (c) PARTITIONS 2;
            		 
            ALTER TABLE t ADD PARTITION PARTITIONS 2;
            		 
            SELECT * FROM t;

            Leads to:

            CS 11.2.6 12a91b57e27b979819924cf89614e6e51f24b37b (Optimized)

            		 
            mysqltest: At line 6: query 'SELECT * FROM t' failed: ER_CRASHED_ON_USAGE (1194): Table 't' is marked as crashed and should be repaired

            And in the error log:

            CS 11.2.6 12a91b57e27b979819924cf89614e6e51f24b37b (Optimized)

            		 
            2024-10-31 16:46:17 4 [Warning] InnoDB: Table test/t#P#p0 contains 2 user defined columns in InnoDB, but 1 columns in MariaDB. Please check INFORMATION_SCHEMA.INNODB_SYS_COLUMNS and https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/ for how to resolve the issue.
            		 
            2024-10-31 16:46:17 4 [ERROR] mariadbd: Table 't' is marked as crashed and should be repaired

            If we use MyISAM instead we get:

            CS 11.2.6 12a91b57e27b979819924cf89614e6e51f24b37b (Optimized)

            		 
            mysqltest: At line 5: query 'SELECT * FROM t' failed: ER_GET_ERRNO (1030): Got error 190 "Incompatible key or row definition between the MariaDB .frm file and the information in the storage engine. You may have retry " from storage engine MyISAM

            Issue confirmed in 10.5-11.7

            Roel Roel Van de Paar added a comment - --source include/have_innodb.inc --source include/have_partition.inc   CREATE TABLE t (c INT , UNIQUE USING HASH (c)) ENGINE=InnoDB PARTITION BY HASH (c) PARTITIONS 2; ALTER TABLE t ADD PARTITION PARTITIONS 2; SELECT * FROM t; Leads to: CS 11.2.6 12a91b57e27b979819924cf89614e6e51f24b37b (Optimized) mysqltest: At line 6: query 'SELECT * FROM t' failed: ER_CRASHED_ON_USAGE (1194): Table 't' is marked as crashed and should be repaired And in the error log: CS 11.2.6 12a91b57e27b979819924cf89614e6e51f24b37b (Optimized) 2024-10-31 16:46:17 4 [Warning] InnoDB: Table test/t#P#p0 contains 2 user defined columns in InnoDB, but 1 columns in MariaDB. Please check INFORMATION_SCHEMA.INNODB_SYS_COLUMNS and https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/ for how to resolve the issue. 2024-10-31 16:46:17 4 [ERROR] mariadbd: Table 't' is marked as crashed and should be repaired If we use MyISAM instead we get: CS 11.2.6 12a91b57e27b979819924cf89614e6e51f24b37b (Optimized) mysqltest: At line 5: query 'SELECT * FROM t' failed: ER_GET_ERRNO (1030): Got error 190 "Incompatible key or row definition between the MariaDB .frm file and the information in the storage engine. You may have retry " from storage engine MyISAM Issue confirmed in 10.5-11.7
            elenst Elena Stepanova added a comment - - edited

            CONVERT PARTITION also fails (applicable to 10.11+)

            --source include/have_innodb.inc
            		 
            --source include/have_partition.inc
            		 
             
            		 
            CREATE TABLE t (a INT, b TEXT, UNIQUE (b)) ENGINE = InnoDB PARTITION BY LIST (a) (PARTITION p0 VALUES IN (1,2), PARTITION pdef DEFAULT);
            		 
            ALTER TABLE t CONVERT PARTITION p0 TO TABLE tp;
            		 
             
            		 
            CHECK TABLE t EXTENDED;
            		 
             
            		 
            # Cleanup
            		 
            DROP TABLE t, tp;

            10.11 b9e592a786a8fc9f12cb80cb42c24e274037f153

            		 
            CHECK TABLE t EXTENDED;
            		 
            Table	Op	Msg_type	Msg_text
            		 
            test.t	check	Error	Table 't' is marked as crashed and should be repaired
            		 
            test.t	check	error	Corrupt
            		 
            DROP TABLE t, tp;
            		 
            bug.r6                                   [ fail ]  Found warnings/errors in server log file!
            		 
                    Test ended at 2024-12-10 01:35:32
            		 
            line
            		 
            2024-12-10  1:35:31 4 [Warning] InnoDB: Table test/t#P#pdef contains 3 user defined columns in InnoDB, but 4 columns in MariaDB. Please check INFORMATION_SCHEMA.INNODB_SYS_COLUMNS and https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/ for how to resolve the issue.
            		 
            2024-12-10  1:35:31 4 [ERROR] mariadbd: Table 't' is marked as crashed and should be repaired

            elenst Elena Stepanova added a comment - - edited CONVERT PARTITION also fails (applicable to 10.11+) --source include/have_innodb.inc --source include/have_partition.inc   CREATE TABLE t (a INT , b TEXT, UNIQUE (b)) ENGINE = InnoDB PARTITION BY LIST (a) (PARTITION p0 VALUES IN (1,2), PARTITION pdef DEFAULT ); ALTER TABLE t CONVERT PARTITION p0 TO TABLE tp;   CHECK TABLE t EXTENDED;   # Cleanup DROP TABLE t, tp; 10.11 b9e592a786a8fc9f12cb80cb42c24e274037f153 CHECK TABLE t EXTENDED; Table Op Msg_type Msg_text test.t check Error Table 't' is marked as crashed and should be repaired test.t check error Corrupt DROP TABLE t, tp; bug.r6 [ fail ] Found warnings/errors in server log file! Test ended at 2024-12-10 01:35:32 line 2024-12-10 1:35:31 4 [Warning] InnoDB: Table test/t#P#pdef contains 3 user defined columns in InnoDB, but 4 columns in MariaDB. Please check INFORMATION_SCHEMA.INNODB_SYS_COLUMNS and https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/ for how to resolve the issue. 2024-12-10 1:35:31 4 [ERROR] mariadbd: Table 't' is marked as crashed and should be repaired
            midenok Aleksey Midenkov added a comment -

            Please review bb-10.5-midenok2

            midenok Aleksey Midenkov added a comment - Please review bb-10.5-midenok2
            nikitamalyavin Nikita Malyavin added a comment -

            commit d06df4b6aacb is ok to push

            nikitamalyavin Nikita Malyavin added a comment - commit d06df4b6aacb is ok to push

            People

              midenok Aleksey Midenkov
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              6 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.