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

Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed upon concurrent DELETE and DDL with virtual blob column

    Details

      Description

      The test case is non-deterministic, run with --repeat (and preferably replace it with something better before adding it to the regression suite).

      --source include/have_innodb.inc
       
      CREATE TABLE t1 (b BLOB, vb TEXT AS (b) PERSISTENT, KEY(vb(64))) ENGINE=InnoDB;
      INSERT INTO t1 (b) VALUES ('foo');
       
      --connect (con1,localhost,root,,test)
      --send
        CREATE TABLE t2 LIKE t1;
       
      --connection default
      DELETE FROM t1;
       
      # Cleanup
      --connection con1
      --reap
      --disconnect con1
      --connection default
      DROP TABLE t1, t2;
      

      10.2 ba10ffe0f4c9

      mysqld: /data/src/10.2/sql/field.cc:8108: virtual String* Field_blob::val_str(String*, String*): Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed.
      180813 19:23:35 [ERROR] mysqld got signal 6 ;
       
      Query (0x7f15f4012478): DELETE FROM t1
      Connection ID (thread ID): 9
      Status: NOT_KILLED
      

      #7  0x00007f164f7e7ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      #8  0x0000563ada3a7236 in Field_blob::val_str (this=0x7f15f400a2b0, val_buffer=0x7f15f400a4b0, val_ptr=0x7f15f400a4b0) at /data/src/10.2/sql/field.cc:8108
      #9  0x0000563ada0849b7 in Field::val_str (this=0x7f15f400a2b0, str=0x7f15f400a4b0) at /data/src/10.2/sql/field.h:865
      #10 0x0000563ada3b3101 in Field_blob::store_field (this=0x7f15f400a3d0, from=0x7f15f400a2b0) at /data/src/10.2/sql/field.h:3303
      #11 0x0000563ada3b7bc7 in field_conv_incompatible (to=0x7f15f400a3d0, from=0x7f15f400a2b0) at /data/src/10.2/sql/field_conv.cc:831
      #12 0x0000563ada3b7c23 in field_conv (to=0x7f15f400a3d0, from=0x7f15f400a2b0) at /data/src/10.2/sql/field_conv.cc:844
      #13 0x0000563ada3e4be9 in save_field_in_field (from=0x7f15f400a2b0, null_value=0x7f15f417a02a, to=0x7f15f400a3d0, no_conversions=false) at /data/src/10.2/sql/item.cc:6370
      #14 0x0000563ada3e4df0 in Item_field::save_in_field (this=0x7f15f4179fb8, to=0x7f15f400a3d0, no_conversions=false) at /data/src/10.2/sql/item.cc:6416
      #15 0x0000563ada25ad01 in TABLE::update_virtual_fields (this=0x7f15f4085660, h=0x7f15f4086268, update_mode=VCOL_UPDATE_FOR_DELETE) at /data/src/10.2/sql/table.cc:7608
      #16 0x0000563ada55dcc2 in mysql_delete (thd=0x7f15f4000b00, table_list=0x7f15f4012540, conds=0x0, order_list=0x7f15f4005070, limit=18446744073709551615, options=0, result=0x0) at /data/src/10.2/sql/sql_delete.cc:565
      #17 0x0000563ada14e25e in mysql_execute_command (thd=0x7f15f4000b00) at /data/src/10.2/sql/sql_parse.cc:4633
      #18 0x0000563ada158a96 in mysql_parse (thd=0x7f15f4000b00, rawbuf=0x7f15f4012478 "DELETE FROM t1", length=14, parser_state=0x7f1648454200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8009
      #19 0x0000563ada146516 in dispatch_command (command=COM_QUERY, thd=0x7f15f4000b00, packet=0x7f15f40967b1 "DELETE FROM t1", packet_length=14, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1824
      #20 0x0000563ada144e79 in do_command (thd=0x7f15f4000b00) at /data/src/10.2/sql/sql_parse.cc:1378
      #21 0x0000563ada296678 in do_handle_one_connection (connect=0x563ade0a0090) at /data/src/10.2/sql/sql_connect.cc:1335
      #22 0x0000563ada296405 in handle_one_connection (arg=0x563ade0a0090) at /data/src/10.2/sql/sql_connect.cc:1241
      #23 0x0000563ada6b8790 in pfs_spawn_thread (arg=0x563ade0c32b0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
      #24 0x00007f16514be494 in start_thread (arg=0x7f1648455700) at pthread_create.c:333
      #25 0x00007f164f8a493f in clone () from /lib/x86_64-linux-gnu/libc.so.6
      

      Doesn't seem to be reproducible on 10.1.
      No visible effect on non-debug builds.

      The problem appeared in 10.2 tree with this commit:

      commit 831df10981b7851871e1f3b8f04079df0cf5da36
      Author: Monty <monty@mariadb.org>
      Date:   Sat Jun 16 12:03:15 2018 +0300
       
          Add PART_INDIRECT_KEY_FLAG
          
          This is to mark that a field is indirectly part of a key, which simplifes
          checking if we need to have this field up to date to evaluate a key.
          
          For example:
          CREATE TABLE t1 (a int, b int as (a) virtual,
                           c int as (b) virtual, index(c))
          would mark a and b with PART_INDIRECT_KEY_FLAG.
      

        Attachments

          Activity

            People

            • Assignee:
              serg Sergei Golubchik
              Reporter:
              elenst Elena Stepanova
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: