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

Assertion `!(length < share->base.min_block_length)' failed in _ma_scan_block_record

    XMLWordPrintable

Details

    Description

      The issue is volatile, run with a really big value in --repeat=N (hundreds).

       
      CREATE TABLE t1 (a INT) ENGINE=Aria;
      CREATE TABLE t2 (b INT) ENGINE=Aria;
       
      --connect (con1,localhost,root,,test)
      --connect (con2,localhost,root,,test)
       
      --connect (con3,localhost,root,,test)
      SELECT * FROM t1;
      CREATE TEMPORARY TABLE tmp1 (c INT) ENGINE=Aria;
      ALTER TABLE tmp1 ADD d CHAR(3);
      CREATE TEMPORARY TABLE tmp2 (e TIMESTAMP) ENGINE=Aria;
      INSERT INTO tmp1 (c) VALUES (1),(2);
      INSERT INTO tmp1 SELECT * FROM tmp1;
      ALTER ONLINE TABLE tmp2 FORCE;
      DELETE FROM tmp1 LIMIT 1;
       
      --connection con2
      --send
        ALTER TABLE t1 /*!100301 NOWAIT */ ADD b VARCHAR(8), ALGORITHM=INPLACE;
       
      --connection default
      SELECT * FROM t2;
       
      --connection con3
      --error ER_BAD_FIELD_ERROR
      ALTER TABLE tmp2 CHANGE IF EXISTS x1 x2 TEXT, ADD x3 VARCHAR(8) AFTER x4;
      OPTIMIZE TABLE tmp1;
      --error WARN_DATA_TRUNCATED
      ALTER TABLE tmp1 CHANGE IF EXISTS b d VARBINARY(4), MODIFY d INT NOT NULL DEFAULT 0, ALTER COLUMN IF EXISTS x SET DEFAULT NULL;
      INSERT INTO tmp2 () VALUES ();
       
      #--error 0,ER_GET_ERRNO
      UPDATE tmp1 SET d = 'foo';
       
      # Cleanup
      --connection con2
      --error ER_ALTER_OPERATION_NOT_SUPPORTED
      --reap
      --disconnect con1
      --disconnect con2
      --disconnect con3
      --connection default
      DROP TABLE t1, t2;
      

      10.3 765ae6e8

      mysqld: /data/src/10.3/storage/maria/ma_blockrec.c:5464: _ma_scan_block_record: Assertion `!(length < share->base.min_block_length)' failed.
      190424 14:48:56 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f057e88dee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      #8  0x000055f320eb1d8f in _ma_scan_block_record (info=0x7f05540f8f10, record=0x7f05540e9bd0 "\377", record_pos=0, skip_deleted=1 '\001') at /data/src/10.3/storage/maria/ma_blockrec.c:5464
      #9  0x000055f320e9e902 in maria_scan (info=0x7f05540f8f10, record=0x7f05540e9bd0 "\377") at /data/src/10.3/storage/maria/ma_scan.c:54
      #10 0x000055f320e47578 in ha_maria::rnd_next (this=0x7f05540ec588, buf=0x7f05540e9bd0 "\377") at /data/src/10.3/storage/maria/ha_maria.cc:2482
      #11 0x000055f32082329f in handler::ha_rnd_next (this=0x7f05540ec588, buf=0x7f05540e9bd0 "\377") at /data/src/10.3/sql/handler.cc:2813
      #12 0x000055f3209a4af3 in rr_sequential (info=0x7f0578955180) at /data/src/10.3/sql/records.cc:481
      #13 0x000055f3204896ab in READ_RECORD::read_record (this=0x7f0578955180) at /data/src/10.3/sql/records.h:73
      #14 0x000055f32061e6f9 in mysql_update (thd=0x7f0554000b00, table_list=0x7f0554013a08, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7f0578955700, updated_return=0x7f05789557c0) at /data/src/10.3/sql/sql_update.cc:865
      #15 0x000055f320525480 in mysql_execute_command (thd=0x7f0554000b00) at /data/src/10.3/sql/sql_parse.cc:4584
      #16 0x000055f32053084b in mysql_parse (thd=0x7f0554000b00, rawbuf=0x7f0554013928 "UPDATE tmp1 SET d = 'foo'", length=25, parser_state=0x7f05789565f0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8091
      #17 0x000055f32051db1a in dispatch_command (command=COM_QUERY, thd=0x7f0554000b00, packet=0x7f055400b1f1 "UPDATE tmp1 SET d = 'foo'", packet_length=25, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1857
      #18 0x000055f32051c504 in do_command (thd=0x7f0554000b00) at /data/src/10.3/sql/sql_parse.cc:1403
      #19 0x000055f32068515b in do_handle_one_connection (connect=0x55f323a193e0) at /data/src/10.3/sql/sql_connect.cc:1402
      #20 0x000055f320684edf in handle_one_connection (arg=0x55f323a193e0) at /data/src/10.3/sql/sql_connect.cc:1308
      #21 0x000055f320a5c04d in pfs_spawn_thread (arg=0x55f32395ec70) at /data/src/10.3/storage/perfschema/pfs.cc:1862
      #22 0x00007f0580982494 in start_thread (arg=0x7f0578957700) at pthread_create.c:333
      #23 0x00007f057e94a93f in clone () from /lib/x86_64-linux-gnu/libc.so.6
      

      If you start getting ER_GET_ERRNO upon UPDATE, but want to get to the assertion failure instead, uncomment the{{--error line}} before it. Naturally, ER_GET_ERRNO itself is also a problem.

      Non-debug build doesn't crash, but quickly enough produces ER_CRASHED_ON_USAGE on the same update.

      The test case isn't applicable directly to 10.2, and I couldn't modify it so that the problem would become reproducible on 10.2.

      Attachments

        Activity

          People

            monty Michael Widenius
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            3 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.