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

Server hangs or fails on assertion after modifying key column to CHAR(0) or BINARY(0), various UBSAN issues

    XMLWordPrintable

Details

    Description

      I'm not setting it to critical even though it's a recent regression, because CHAR(0) isn't a realistic use case (I hope).

      --source include/have_innodb.inc
       
      CREATE TABLE t (id INT PRIMARY KEY) ENGINE=innodb;
      --error 0,ER_WRONG_KEY_COLUMN
      ALTER TABLE t MODIFY id CHAR(0);
      UPDATE t SET id = 1;
       
      DROP TABLE t;
      

      10.5 da20e4d8a57f0fd957edcaa50299173ccc8cac86

      mariadbd: /data/bld/10.5-asan/storage/innobase/handler/ha_innodb.cc:8859: virtual int ha_innobase::index_read(uchar*, const uchar*, uint, ha_rkey_function): Assertion `key_len != 0 || find_flag != HA_READ_KEY_EXACT' failed.
      250401  1:18:06 [ERROR] /share8t/bld/10.5-asan/sql/mariadbd got signal 6 ;
       
      #9  0x00007f304ea53eb2 in __GI___assert_fail (assertion=0x56452421e8c0 "key_len != 0 || find_flag != HA_READ_KEY_EXACT", file=0x564524211320 "/data/bld/10.5-asan/storage/innobase/handler/ha_innodb.cc", line=8859, function=0x56452421e920 "virtual int ha_innobase::index_read(uchar*, const uchar*, uint, ha_rkey_function)") at ./assert/assert.c:101
      #10 0x00005645228c5ac6 in ha_innobase::index_read (this=0x61d0002af8b8, buf=0x6190000fc3c8 "\377", '\276' <repeats 23 times>, "8\304\017", key_ptr=0x6190000fc648 '\276' <repeats 200 times>..., key_len=0, find_flag=HA_READ_KEY_EXACT) at /data/bld/10.5-asan/storage/innobase/handler/ha_innodb.cc:8859
      #11 0x00005645228c9fa3 in ha_innobase::rnd_pos (this=0x61d0002af8b8, buf=0x6190000fc3c8 "\377", '\276' <repeats 23 times>, "8\304\017", pos=0x6190000fc648 '\276' <repeats 200 times>...) at /data/bld/10.5-asan/storage/innobase/handler/ha_innodb.cc:9428
      #12 0x0000564521e49b88 in handler::ha_rnd_pos (this=0x61d0002af8b8, buf=0x6190000fc3c8 "\377", '\276' <repeats 23 times>, "8\304\017", pos=0x6190000fc648 '\276' <repeats 200 times>...) at /data/bld/10.5-asan/sql/handler.cc:3223
      #13 0x00005645222ae7bb in rr_from_tempfile (info=0x7f30372218e0) at /data/bld/10.5-asan/sql/records.cc:535
      #14 0x00005645214205a8 in READ_RECORD::read_record (this=0x7f30372218e0) at /data/bld/10.5-asan/sql/records.h:80
      #15 0x0000564521900fa7 in mysql_update (thd=0x62b00007e218, table_list=0x62b000085338, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7f3037222030, updated_return=0x7f3037222050) at /data/bld/10.5-asan/sql/sql_update.cc:1024
      #16 0x00005645215e7427 in mysql_execute_command (thd=0x62b00007e218) at /data/bld/10.5-asan/sql/sql_parse.cc:4507
      #17 0x0000564521600f03 in mysql_parse (thd=0x62b00007e218, rawbuf=0x62b000085238 "UPDATE t SET id = 1", length=19, parser_state=0x7f3037222c70, is_com_multi=false, is_next_command=false) at /data/bld/10.5-asan/sql/sql_parse.cc:8252
      #18 0x00005645215d60c6 in dispatch_command (command=COM_QUERY, thd=0x62b00007e218, packet=0x62900026c219 "UPDATE t SET id = 1", packet_length=19, is_com_multi=false, is_next_command=false) at /data/bld/10.5-asan/sql/sql_parse.cc:1891
      #19 0x00005645215d2a59 in do_command (thd=0x62b00007e218) at /data/bld/10.5-asan/sql/sql_parse.cc:1375
      #20 0x0000564521a30135 in do_handle_one_connection (connect=0x608000003eb8, put_in_cache=true) at /data/bld/10.5-asan/sql/sql_connect.cc:1386
      #21 0x0000564521a2fc9b in handle_one_connection (arg=0x608000003e38) at /data/bld/10.5-asan/sql/sql_connect.cc:1298
      #22 0x000056452268fdc8 in pfs_spawn_thread (arg=0x61500000e198) at /data/bld/10.5-asan/storage/perfschema/pfs.cc:2201
      #23 0x00007f304eaa81c4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
      #24 0x00007f304eb2885c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
      

      The failure started happening after this commit in 10.5.28:

      commit ecaedbe299fe11372c36319f9b732b81e9f54883 (HEAD)
      Author:     Nikita Malyavin
      AuthorDate: Sat Oct 12 21:32:18 2024 +0200
      Commit:     Nikita Malyavin
      CommitDate: Sun Jan 26 16:15:46 2025 +0100
       
          MDEV-33658 1/2 Refactoring: extract Key length initialization
      

      Before the commit, ALTER would return ER_WRONG_KEY_COLUMN. After the commit, ALTER succeeds, and the UPDATE causes the assertion failure.
      A non-debug server hangs instead.

      Attachments

        Issue Links

          Activity

            People

              nikitamalyavin Nikita Malyavin
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              5 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.