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

Assertion `0' failed in btr_page_reorganize_low upon DROP COLUMN

Details

    Description

      --source include/have_innodb.inc
      		 
       
      		 
      CREATE TABLE t1 (
      		 
        pk INT,
      		 
        i INT,
      		 
        b TINYBLOB NOT NULL,
      		 
        primary key (pk)
      		 
      ) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;
      		 
       
      		 
      INSERT INTO t1 VALUES  (1,10,'foo');
      		 
      ALTER TABLE t1 DROP COLUMN b;
      		 
      REPLACE INTO t1 VALUES (2,20);
      		 
       
      		 
      --source include/restart_mysqld.inc
      		 
       
      		 
      ALTER TABLE t1 DROP COLUMN i;
      		 
       
      		 
      # Cleanup
      		 
      DROP TABLE t1;

      10.4 301bd62b253

      		 
      2019-01-12 20:09:35 8 [ERROR] InnoDB: Page old data size 125 new data size 296, page old max ins size 16125 new max ins size 15954
      		 
      2019-01-12 20:09:35 8 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
      		 
      mysqld: /data/src/10.4/storage/innobase/btr/btr0btr.cc:1670: bool btr_page_reorganize_low(bool, ulint, page_cur_t*, dict_index_t*, mtr_t*): Assertion `0' failed.
      		 
      190112 20:09:35 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      #7  0x00007f035d242ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      		 
      #8  0x00005626630a19ed in btr_page_reorganize_low (recovery=false, z_level=6, cursor=0x7f035256fde8, index=0x7f0328014eb8, mtr=0x7f035256ff00) at /data/src/10.4/storage/innobase/btr/btr0btr.cc:1670
      		 
      #9  0x00005626630a2180 in btr_page_reorganize (cursor=0x7f035256fde8, index=0x7f0328014eb8, mtr=0x7f035256ff00) at /data/src/10.4/storage/innobase/btr/btr0btr.cc:1825
      		 
      #10 0x00005626630ce340 in btr_cur_pessimistic_update (flags=10, cursor=0x7f035256fde0, offsets=0x7f035256fd00, offsets_heap=0x7f035256fd08, entry_heap=0x7f030c055d40, big_rec=0x7f035256fd10, update=0x7f030c058840, cmpl_info=1, thr=0x7f030c058788, trx_id=48, mtr=0x7f035256ff00) at /data/src/10.4/storage/innobase/btr/btr0cur.cc:5047
      		 
      #11 0x0000562662ea79c8 in innobase_instant_try (ha_alter_info=0x7f0352571bc0, ctx=0x7f030c0186f8, altered_table=0x7f030c053dc0, table=0x7f030c029a90, trx=0x7f0358011258) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:5713
      		 
      #12 0x0000562662ec2a0f in commit_try_norebuild (ha_alter_info=0x7f0352571bc0, ctx=0x7f030c0186f8, altered_table=0x7f030c053dc0, old_table=0x7f030c029a90, trx=0x7f0358011258, table_name=0x7f030c0278ad "t1") at /data/src/10.4/storage/innobase/handler/handler0alter.cc:10138
      		 
      #13 0x0000562662eb52d4 in ha_innobase::commit_inplace_alter_table (this=0x7f030c02ab28, altered_table=0x7f030c053dc0, ha_alter_info=0x7f0352571bc0, commit=true) at /data/src/10.4/storage/innobase/handler/handler0alter.cc:10767
      		 
      #14 0x0000562662b44cf4 in handler::ha_commit_inplace_alter_table (this=0x7f030c02ab28, altered_table=0x7f030c053dc0, ha_alter_info=0x7f0352571bc0, commit=true) at /data/src/10.4/sql/handler.cc:4492
      		 
      #15 0x000056266290451c in mysql_inplace_alter_table (thd=0x7f030c000b00, table_list=0x7f030c017360, table=0x7f030c029a90, altered_table=0x7f030c053dc0, ha_alter_info=0x7f0352571bc0, inplace_supported=HA_ALTER_INPLACE_INSTANT, target_mdl_request=0x7f0352571cf0, alter_ctx=0x7f03525728e0) at /data/src/10.4/sql/sql_table.cc:7590
      		 
      #16 0x000056266290a37d in mysql_alter_table (thd=0x7f030c000b00, new_db=0x7f030c0051c8, new_name=0x7f030c005598, create_info=0x7f03525734d0, table_list=0x7f030c017360, alter_info=0x7f0352573410, order_num=0, order=0x0, ignore=false) at /data/src/10.4/sql/sql_table.cc:9690
      		 
      #17 0x00005626629949fb in Sql_cmd_alter_table::execute (this=0x7f030c0179c8, thd=0x7f030c000b00) at /data/src/10.4/sql/sql_alter.cc:497
      		 
      #18 0x0000562662831c96 in mysql_execute_command (thd=0x7f030c000b00) at /data/src/10.4/sql/sql_parse.cc:6302
      		 
      #19 0x0000562662836bc2 in mysql_parse (thd=0x7f030c000b00, rawbuf=0x7f030c017278 "ALTER TABLE t1 DROP COLUMN i", length=28, parser_state=0x7f0352574600, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8104
      		 
      #20 0x0000562662823dec in dispatch_command (command=COM_QUERY, thd=0x7f030c000b00, packet=0x7f030c00b421 "ALTER TABLE t1 DROP COLUMN i", packet_length=28, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1851
      		 
      #21 0x0000562662822810 in do_command (thd=0x7f030c000b00) at /data/src/10.4/sql/sql_parse.cc:1396
      		 
      #22 0x000056266298ea3e in do_handle_one_connection (connect=0x5626663d3220) at /data/src/10.4/sql/sql_connect.cc:1402
      		 
      #23 0x000056266298e7c2 in handle_one_connection (arg=0x5626663d3220) at /data/src/10.4/sql/sql_connect.cc:1308
      		 
      #24 0x0000562662e4dc90 in pfs_spawn_thread (arg=0x5626663ce1c0) at /data/src/10.4/storage/perfschema/pfs.cc:1862
      		 
      #25 0x00007f035ef19494 in start_thread (arg=0x7f0352575700) at pthread_create.c:333
      		 
      #26 0x00007f035d2ff93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

      Not reproducible on 10.3.
      A non-debug build doesn't crash, but the preceding ERROR records happen there as well.

      According to my notes, the same assertion failure might happen without server restart, I mentioned it in MDEV-18146 which shouldn't have involved any restart, but I didn't have a reproducible test case there.

      Attachments

        Activity

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

          Finally, I narrowed down the problem. rec_get_offsets() is wrong for the instantly dropped column b in the record (2,20); the record is being interpreted to be larger than it actually is.

          Another bug: We are even inserting a BLOB for the dropped column b, apparently for 65535 bytes. This BLOB should not be created at all.

          If the BLOB were inserted (before dropping the column), we should make sure that DATA_BIG_COL(col) holds. Currently, it fails to hold for the dropped column, because col->len==255. It should be at least 256. Fixing this may require a change to the MDEV-15562 metadata format.

          marko Marko Mäkelä added a comment - Finally, I narrowed down the problem. rec_get_offsets() is wrong for the instantly dropped column b in the record (2,20); the record is being interpreted to be larger than it actually is. Another bug: We are even inserting a BLOB for the dropped column b , apparently for 65535 bytes. This BLOB should not be created at all. If the BLOB were inserted (before dropping the column), we should make sure that DATA_BIG_COL(col) holds. Currently, it fails to hold for the dropped column, because col->len==255 . It should be at least 256 . Fixing this may require a change to the MDEV-15562 metadata format.
          marko Marko Mäkelä added a comment -

          Even after fixing the side problem, I can repeat the originally reported problem:

          CREATE TABLE t1 (
          		 
            pk INT PRIMARY KEY,
          		 
            i INT,
          		 
            b BLOB NOT NULL
          		 
          ) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;
          		 
           
          		 
          INSERT INTO t1 VALUES  (1,10,'foo'),(2,20,REPEAT('foobar',2000));
          		 
          ALTER TABLE t1 DROP COLUMN b;
          		 
           
          		 
          ALTER TABLE t1 ADD COLUMN vpk INT AS (pk);
          		 
          ALTER TABLE t1 DROP COLUMN i;
          		 
          DROP TABLE t1;

          The original test case would pass after this fix:

          diff --git a/storage/innobase/row/row0ins.cc b/storage/innobase/row/row0ins.cc
          		 
          index 27df0a9249d..e2ac60c1103 100644
          		 
          --- a/storage/innobase/row/row0ins.cc
          		 
          +++ b/storage/innobase/row/row0ins.cc
          		 
          @@ -3462,8 +3462,9 @@ row_ins_index_entry_set_vals(
          		 
           				field->type.prtype = DATA_BINARY_TYPE;
          		 
           			} else {
          		 
           				ut_ad(col->len <= sizeof field_ref_zero);
          		 
          +				ut_ad(ind_field->fixed_len <= col->len);
          		 
           				dfield_set_data(field, field_ref_zero,
          		 
          -						col->len);
          		 
          +						ind_field->fixed_len);
          		 
           				field->type.prtype = DATA_NOT_NULL;
          		 
           			}

          marko Marko Mäkelä added a comment - Even after fixing the side problem, I can repeat the originally reported problem: CREATE TABLE t1 ( pk INT PRIMARY KEY , i INT , b BLOB NOT NULL ) ENGINE=InnoDB ROW_FORMAT= DYNAMIC ;   INSERT INTO t1 VALUES (1,10, 'foo' ),(2,20,REPEAT( 'foobar' ,2000)); ALTER TABLE t1 DROP COLUMN b;   ALTER TABLE t1 ADD COLUMN vpk INT AS (pk); ALTER TABLE t1 DROP COLUMN i; DROP TABLE t1; The original test case would pass after this fix: diff --git a/storage/innobase/row/row0ins.cc b/storage/innobase/row/row0ins.cc index 27df0a9249d..e2ac60c1103 100644 --- a/storage/innobase/row/row0ins.cc +++ b/storage/innobase/row/row0ins.cc @@ -3462,8 +3462,9 @@ row_ins_index_entry_set_vals( field->type.prtype = DATA_BINARY_TYPE; } else { ut_ad(col->len <= sizeof field_ref_zero); + ut_ad(ind_field->fixed_len <= col->len); dfield_set_data(field, field_ref_zero, - col->len); + ind_field->fixed_len); field->type.prtype = DATA_NOT_NULL; }

          People

            marko Marko Mäkelä
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            2 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.