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

Assertion `rlen < llen' failed in log_phys_t::apply_status log_phys_t::apply upon MariaBackup prepare

    XMLWordPrintable

    Details

      Description

      --source include/have_innodb.inc
       
      CREATE TABLE t1 (pk INT PRIMARY KEY, a YEAR) ENGINE=InnoDB ROW_FORMAT=REDUNDANT;
      INSERT INTO t1 VALUES (1,2021);
      UPDATE t1 SET a = NULL;
      --exec $XTRABACKUP --backup --target-dir=$MYSQLTEST_VARDIR/mbackup_backup --protocol=tcp --port=$MASTER_MYPORT --user=root
      --exec $XTRABACKUP --prepare --target-dir=$MYSQLTEST_VARDIR/mbackup_backup
       
      # Cleanup
      DROP TABLE t1;
      

      10.5 b3df194e

      mariabackup: /data/src/10.5/storage/innobase/log/log0recv.cc:493: log_phys_t::apply_status log_phys_t::apply(const buf_block_t&, uint16_t&) const: Assertion `rlen < llen' failed.
      210214 18:48:09 [ERROR] mysqld got signal 6 ;
       
      #6  0x00007f45bba53f36 in __GI___assert_fail (assertion=0x55cf22c804d8 "rlen < llen", file=0x55cf22c80040 "/data/src/10.5/storage/innobase/log/log0recv.cc", line=493, function=0x55cf22c801c0 "log_phys_t::apply_status log_phys_t::apply(const buf_block_t&, uint16_t&) const") at assert.c:101
      #7  0x000055cf224e77ff in log_phys_t::apply (this=0x7f45ade293d0, block=..., last_offset=@0x55cf252daa64: 152) at /data/src/10.5/storage/innobase/log/log0recv.cc:493
      #8  0x000055cf224de6b8 in recv_recover_page (block=0x7f45adc01ab8, mtr=..., p=Python Exception <class 'AttributeError'> 'NoneType' object has no attribute 'pointer': 
      ..., space=0x55cf252c7e08, init=0x55cf252daac0) at /data/src/10.5/storage/innobase/log/log0recv.cc:2330
      #9  0x000055cf224ea65e in recv_sys_t::recover_low (this=0x55cf23312400 <recv_sys>, page_id=..., p=Python Exception <class 'AttributeError'> 'NoneType' object has no attribute 'pointer': 
      ..., mtr=..., b=0x7f45adc01ab8) at /data/src/10.5/storage/innobase/log/log0recv.cc:2577
      #10 0x000055cf224dfd88 in recv_sys_t::apply (this=0x55cf23312400 <recv_sys>, last_batch=true) at /data/src/10.5/storage/innobase/log/log0recv.cc:2680
      #11 0x000055cf22624d40 in srv_start (create_new_db=false) at /data/src/10.5/storage/innobase/srv/srv0start.cc:1491
      #12 0x000055cf2198ed2b in innodb_init () at /data/src/10.5/extra/mariabackup/xtrabackup.cc:2198
      #13 0x000055cf21999c11 in xtrabackup_prepare_func (argv=0x55cf24d5c998) at /data/src/10.5/extra/mariabackup/xtrabackup.cc:5776
      #14 0x000055cf2199c5ea in main_low (argv=0x55cf24d5c998) at /data/src/10.5/extra/mariabackup/xtrabackup.cc:6681
      #15 0x000055cf2199bdfd in main (argc=3, argv=0x7fffaadc3678) at /data/src/10.5/extra/mariabackup/xtrabackup.cc:6473
      

      The test case appears to be deterministic, at least for the time being.
      Reproducible on 10.5, 10.6.
      10.4 does not seem to have this assertion.
      No obvious immediate problem on a non-debug build (prepare works, server can start on the prepared datadir, and the table is functonal).

      Can also be reproduced with rr. Test case for running with rr (to store mariabackup profiles in addition to the server one, which is done automatically):

      --source include/have_innodb.inc
       
      CREATE TABLE t1 (pk INT PRIMARY KEY, a YEAR) ENGINE=InnoDB ROW_FORMAT=REDUNDANT;
      INSERT INTO t1 VALUES (1,2021);
      UPDATE t1 SET a = NULL;
      --exec rr record --output-trace-dir=$MYSQLTEST_VARDIR/rr.1/rr-mbackup-backup $XTRABACKUP --backup --target-dir=$MYSQLTEST_VARDIR/mbackup_backup --protocol=tcp --port=$MASTER_MYPORT --user=root
      --exec rr record --output-trace-dir=$MYSQLTEST_VARDIR/rr.1/rr-mbackup-prepare $XTRABACKUP --prepare --target-dir=$MYSQLTEST_VARDIR/mbackup_backup
       
      # Cleanup
      DROP TABLE t1;
      

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              marko Marko Mäkelä
              Reporter:
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: