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

Assertion `!__asan_region_is_poisoned((vo id*) dest,templ->mysql_col_len)' failed in void row_sel_field_store_in_mysql_format_func(byte *, const mysql_row_templ_t *, const byte *, ulint)

Details

    Description

      --source include/have_innodb.inc
       
      SET sql_mode='';
      CREATE TABLE t (a CHAR(205)) ENGINE=INNODB CHARACTER SET filename;
      INSERT INTO t VALUES (1);
      SELECT * FROM t;
      

      Leads to:

      CS 11.7.0 35cebfdc513f92b143b1a7229c480f4f684f1698 (Optimized, UBASAN)

      mariadbd: /test/11.7_opt_san/storage/innobase/row/row0sel.cc:2808: void row_sel_field_store_in_mysql_format_func(byte *, const mysql_row_templ_t *, const byte *, ulint): Assertion `!__asan_region_is_poisoned((void*) dest,templ->mysql_col_len)' failed.
      

      CS 11.7.0 35cebfdc513f92b143b1a7229c480f4f684f1698 (Optimized, UBASAN)

      Core was generated by `/test/UBASAN_MD171024-mariadb-11.7.0-linux-x86_64-opt/bin/mariadbd --no-default'.
      Program terminated with signal SIGABRT, Aborted.
      #0  __pthread_kill (threadid=<optimized out>, signo=6)at ../sysdeps/unix/sysv/linux/pthread_kill.c:56
      [Current thread is 1 (Thread 0x154344f8c700 (LWP 706604))]
      (gdb) bt
      #0  __pthread_kill (threadid=<optimized out>, signo=6) at ../sysdeps/unix/sysv/linux/pthread_kill.c:56
      #1  0x00000000015a1356 in handle_fatal_signal (sig=<optimized out>) at signal_handler.cc:366
      #2  <signal handler called>
      #3  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
      #4  0x0000154367f0c859 in __GI_abort () at abort.c:79
      #5  0x0000154367f0c729 in __assert_fail_base (fmt=0x1543680a2588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x3120a00 <str> "!__asan_region_is_poisoned((void*) dest,templ->mysql_col_len)", file=0x3120740 <str> "/test/11.7_opt_san/storage/innobase/row/row0sel.cc", line=2808, function=<optimized out>) at assert.c:92
      #6  0x0000154367f1dfd6 in __GI___assert_fail (assertion=0x3120a00 <str> "!__asan_region_is_poisoned((void*) dest,templ->mysql_col_len)", file=0x3120740 <str> "/test/11.7_opt_san/storage/innobase/row/row0sel.cc", line=2808, function=0x3120a60 <__PRETTY_FUNCTION__._Z40row_sel_field_store_in_mysql_format_funcPhPK17mysql_row_templ_tPKhm> "void row_sel_field_store_in_mysql_format_func(byte *, const mysql_row_templ_t *, const byte *, ulint)") at assert.c:101
      #7  0x000000000224d1aa in row_sel_field_store_in_mysql_format_func (dest=0x61d0000636b9 "", templ=0x60d000006f90, data=0x1543526e8092 <error: Cannot access memory at address 0x1543526e8092>, len=1) at row/row0sel.cc:2808
      #8  0x00000000022702a9 in row_sel_store_mysql_field (mysql_rec=<optimized out>, prebuilt=<optimized out>, rec=<optimized out>, index=<optimized out>, offsets=0x154344f878a0, field_no=3, templ=<optimized out>) at row/row0sel.cc:3100
      #9  0x000000000225edd7 in row_sel_store_mysql_rec (mysql_rec=0x61d0000636b8 "\377", prebuilt=0x154344f86760, rec=0x1543526e807f <error: Cannot access memory at address 0x1543526e807f>, vrow=<optimized out>, rec_clust=false, index=0x6160000438f0, offsets=0x154344f878a0) at row/row0sel.cc:3236
      #10 0x0000000002258b36 in row_search_mvcc (buf=<optimized out>, mode=PAGE_CUR_G, prebuilt=0x61f0000118f0, match_mode=<optimized out>, direction=<optimized out>) at row/row0sel.cc:5702
      #11 0x0000000001f3e3ef in ha_innobase::index_read (this=0x61d000062cb8, buf=0x2 <error: Cannot access memory at address 0x2>, key_ptr=0x0, key_len=0, find_flag=<optimized out>) at handler/ha_innodb.cc:8989
      #12 0x0000000001f3f5ed in ha_innobase::index_first (this=0x61d000062cb8, buf=0x61d0000636b8 "\377") at handler/ha_innodb.cc:9325
      #13 ha_innobase::rnd_next (this=0x61d000062cb8, buf=0x61d0000636b8 "\377") at handler/ha_innodb.cc:9429
      #14 0x00000000015b6070 in handler::ha_rnd_next (this=<optimized out>, buf=0x61d0000636b8 "\377") at handler.cc:3731
      #15 0x0000000000906d01 in rr_sequential (info=0x6290000a3360) at records.cc:513
      #16 0x0000000000ce2c59 in sub_select (join=<optimized out>, join_tab=0x6290000a3290, end_of_records=<optimized out>) at sql_select.cc:24058
      #17 0x0000000000d5dc5d in do_select (join=0x6290000a1a00, procedure=<optimized out>) at sql_select.cc:23572
      #18 JOIN::exec_inner (this=0x6290000a1a00) at sql_select.cc:5043
      #19 0x0000000000d5a16c in JOIN::exec (this=0x6290000a1a00) at sql_select.cc:4826
      #20 0x0000000000ce4f6c in mysql_select (thd=<optimized out>, tables=0x6290000a0938, fields=<optimized out>, conds=0x0, og_num=0, order=<optimized out>, group=0x0, having=0x0, proc_param=0x0, select_options=<optimized out>, result=0x6290000a19d0, unit=0x62b000162360, select_lex=0x6290000a02c0) at sql_select.cc:5359
      #21 0x0000000000ce42b7 in handle_select (thd=0x62b00015e218, lex=0x62b000162280, result=0x6290000a19d0, setup_tables_done_option=0) at sql_select.cc:642
      #22 0x0000000000c1d5b6 in execute_sqlcom_select (thd=0x62b00015e218, all_tables=<optimized out>) at sql_parse.cc:6167
      #23 0x0000000000c0c9e1 in mysql_execute_command (thd=0x62b00015e218, is_called_from_prepared_stmt=<optimized out>) at sql_parse.cc:3954
      #24 0x0000000000bf88b1 in mysql_parse (thd=0x62b00015e218, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at sql_parse.cc:7889
      #25 0x0000000000bf212f in dispatch_command (command=<optimized out>, thd=0x62b00015e218, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at sql_parse.cc:1892
      #26 0x0000000000bf958a in do_command (thd=0x62b00015e218, blocking=true) at sql_parse.cc:1405
      #27 0x00000000010b3043 in do_handle_one_connection (connect=<optimized out>, put_in_cache=<optimized out>) at sql_connect.cc:1448
      #28 0x00000000010b2668 in handle_one_connection (arg=0x608000002638) at sql_connect.cc:1350
      #29 0x00001543682f3609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #30 0x0000154368009133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      Attachments

        Issue Links

          Activity

            Are the affected versions set correctly? I couldn’t reproduce this in a 10.6 based branch, nor on 11.4 41f54da46f491e968651d5083ff86a78a8635f55.

            In fact, I couldn’t reproduce this on the current head of the main branch (54ab281de85f53e4fa7ba07384bed388737681e6), nor with the reported revision. Initially I had only enabled -fsanitize=address (cmake -DWITH_ASAN=ON), but I rebuilt with -fsanitize=undefined (cmake -DWITH_UBSAN=ON) with the same result, using GCC 13.2.0. The only errors that I got were the following:

            main 35cebfdc513f92b143b1a7229c480f4f684f1698

            sql/sys_vars.inl:463:24: runtime error: store to address 0x57b994a19e80 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:198:18: runtime error: store to address 0x57b99ba93120 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:529:28: runtime error: store to address 0x57b99ba8d640 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:198:18: runtime error: store to address 0x57b99ba92d20 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:1961:8: runtime error: load of address 0x57b99ba92a20 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:1961:26: runtime error: store to address 0x57b99ba92a20 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:394:22: runtime error: store to address 0x57b99ae9fde0 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:198:18: runtime error: store to address 0x57b99ba92be0 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:890:35: runtime error: store to address 0x57b99ba94708 with insufficient space for an object of type 'size_t'
            sql/sys_vars.inl:890:35: runtime error: store to address 0x57b99ba946c8 with insufficient space for an object of type 'size_t'
            sql/sys_vars.inl:1529:26: runtime error: store to address 0x57b99ba92e20 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:198:18: runtime error: store to address 0x57b99bac0b64 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:433:18: runtime error: load of address 0x57b9997cc1a0 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:2288:18: runtime error: load of address 0x57b99ba8ec80 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:2011:18: runtime error: load of address 0x57b99ba92a20 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:1616:18: runtime error: load of address 0x57b99ba8c460 with insufficient space for an object of type 'uchar'
            sql/sys_vars.inl:1853:18: runtime error: load of address 0x57b99ba94880 with insufficient space for an object of type 'uchar'
            

            Can you provide an rr replay trace of the failure?

            marko Marko Mäkelä added a comment - Are the affected versions set correctly? I couldn’t reproduce this in a 10.6 based branch, nor on 11.4 41f54da46f491e968651d5083ff86a78a8635f55. In fact, I couldn’t reproduce this on the current head of the main branch (54ab281de85f53e4fa7ba07384bed388737681e6), nor with the reported revision. Initially I had only enabled -fsanitize=address ( cmake -DWITH_ASAN=ON ), but I rebuilt with -fsanitize=undefined ( cmake -DWITH_UBSAN=ON ) with the same result, using GCC 13.2.0. The only errors that I got were the following: main 35cebfdc513f92b143b1a7229c480f4f684f1698 sql/sys_vars.inl:463:24: runtime error: store to address 0x57b994a19e80 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:198:18: runtime error: store to address 0x57b99ba93120 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:529:28: runtime error: store to address 0x57b99ba8d640 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:198:18: runtime error: store to address 0x57b99ba92d20 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:1961:8: runtime error: load of address 0x57b99ba92a20 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:1961:26: runtime error: store to address 0x57b99ba92a20 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:394:22: runtime error: store to address 0x57b99ae9fde0 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:198:18: runtime error: store to address 0x57b99ba92be0 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:890:35: runtime error: store to address 0x57b99ba94708 with insufficient space for an object of type 'size_t' sql/sys_vars.inl:890:35: runtime error: store to address 0x57b99ba946c8 with insufficient space for an object of type 'size_t' sql/sys_vars.inl:1529:26: runtime error: store to address 0x57b99ba92e20 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:198:18: runtime error: store to address 0x57b99bac0b64 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:433:18: runtime error: load of address 0x57b9997cc1a0 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:2288:18: runtime error: load of address 0x57b99ba8ec80 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:2011:18: runtime error: load of address 0x57b99ba92a20 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:1616:18: runtime error: load of address 0x57b99ba8c460 with insufficient space for an object of type 'uchar' sql/sys_vars.inl:1853:18: runtime error: load of address 0x57b99ba94880 with insufficient space for an object of type 'uchar' Can you provide an rr replay trace of the failure?

            I also gave Clang 19.1.0 a try on the reported revision, only defining cmake -DWITH_ASAN because I expect various trouble from -fsanitize=undefined until issues like MDEV-34348 have been fixed. I was unable to reproduce this.

            marko Marko Mäkelä added a comment - I also gave Clang 19.1.0 a try on the reported revision, only defining cmake -DWITH_ASAN because I expect various trouble from -fsanitize=undefined until issues like MDEV-34348 have been fixed. I was unable to reproduce this.

            Based on the trace that I analyzed, this looks like a buffer overflow:

            10.6 ba4541ba7f0d89e7825f1dae44eb96142b25138b

            0x00000000007c5395 in __asan_memcpy ()
            1: x/i $pc
            => 0x7c5395 <__asan_memcpy+117>:	lea    (%r15,%rbx,1),%rax
            (rr) i reg rbx
            rbx            0x402               1026
            (rr) bt
            #0  0x00000000007c5395 in __asan_memcpy ()
            #1  0x0000000000ec12e4 in TABLE::init (this=0x619000064598, thd=<optimized out>, tl=<optimized out>) at table.cc:5787
            #2  0x0000000000981d25 in open_table (thd=<optimized out>, table_list=0x62b0000a1938, ot_ctx=0x2b3f63301160) at sql_base.cc:2175
            #3  0x000000000098b7f9 in open_and_process_table (thd=0x62b00009a218, tables=0x62b0000a1938, counter=0x2b3f633014c0, flags=0, prelocking_strategy=0x2b3f633015e0, ot_ctx=0x2b3f63301160, 
                has_prelocking_list=<optimized out>) at sql_base.cc:3877
            #4  open_tables (thd=<optimized out>, options=<optimized out>, start=<optimized out>, counter=<optimized out>, flags=<optimized out>, prelocking_strategy=<optimized out>) at sql_base.cc:4361
            #5  0x000000000099518e in open_and_lock_tables (thd=<optimized out>, options=<optimized out>, tables=<optimized out>, derived=<optimized out>, flags=<optimized out>, prelocking_strategy=<optimized out>)
                at sql_base.cc:5333
            #6  0x0000000000b4186b in open_and_lock_tables (thd=0x62b00009a218, tables=0x62b0000a1938, derived=255, flags=0) at sql_base.h:515
            #7  execute_sqlcom_select (thd=0x62b00009a218, all_tables=<optimized out>) at sql_parse.cc:6328
            #8  0x0000000000b3002f in mysql_execute_command (thd=0x62b00009a218, is_called_from_prepared_stmt=<optimized out>) at sql_parse.cc:3999
            #9  0x0000000000b1be41 in mysql_parse (thd=0x62b00009a218, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at sql_parse.cc:8194
            #10 0x0000000000b15b01 in dispatch_command (command=<optimized out>, thd=0x62b00009a218, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at sql_parse.cc:1908
            #11 0x0000000000b1cb1a in do_command (thd=0x62b00009a218, blocking=true) at sql_parse.cc:1421
            #12 0x0000000000f78185 in do_handle_one_connection (connect=<optimized out>, put_in_cache=<optimized out>) at sql_connect.cc:1407
            #13 0x0000000000f778ac in handle_one_connection (arg=0x608000002d38) at sql_connect.cc:1319
            #14 0x00001500733dc609 in start_thread (arg=<optimized out>) at pthread_create.c:477
            #15 0x00001e044af8a353 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
            

            Here, the length seems to be 1026 bytes. But, a little before the assertion failure:

            10.6 ba4541ba7f0d89e7825f1dae44eb96142b25138b

            #0  0x00000000007c8440 in __asan_region_is_poisoned ()
            #1  0x00000000020f0d56 in row_sel_field_store_in_mysql_format_func (dest=0x61d0000532b9 "", templ=0x60d000010030, data=0x66466b994092 "1", len=1) at row/row0sel.cc:2809
            #2  0x00000000021140a9 in row_sel_store_mysql_field (mysql_rec=<optimized out>, prebuilt=<optimized out>, rec=<optimized out>, index=<optimized out>, offsets=0x2b3f632ffee0, field_no=3, templ=<optimized out>)
                at row/row0sel.cc:3101
            #3  0x00000000021033f7 in row_sel_store_mysql_rec (mysql_rec=0x61d0000532b8 "\377", prebuilt=0x403, rec=0x66466b99407f "", vrow=<optimized out>, rec_clust=false, index=0x616000032df0, offsets=0x2b3f632ffee0)
                at row/row0sel.cc:3237
            …
            (rr) frame 1
            #1  0x00000000020f0d56 in row_sel_field_store_in_mysql_format_func (dest=0x61d0000532b9 "", templ=0x60d000010030, data=0x66466b994092 "1", len=1) at row/row0sel.cc:2809
            2809		MEM_CHECK_ADDRESSABLE(dest, templ->mysql_col_len);
            (rr) print *templ
            $4 = {col_no = 0, rec_field_no = 3, rec_field_is_prefix = 0, rec_prefix_field_no = 18446744073709551615, clust_rec_field_no = 3, icp_rec_field_no = 13744632839234567870, mysql_col_offset = 1, 
              mysql_col_len = 1027, mysql_null_byte_offset = 0, mysql_null_bit_mask = 1, type = 12, mysql_type = 15, mysql_length_bytes = 2, charset = 17, mbminlen = 1, mbmaxlen = 5, is_unsigned = 0, is_virtual = 0}
            

            we can see that we are trying to access 1027=2+5*205 bytes within something that is at most 1026 bytes long. I assume that the 2 bytes are for storing the length of the VARCHAR column. In the filename character set, each source character occupies 1, 3, or 5 ASCII characters per source character. A long enough CHAR column will be treated as VARCHAR.

            In any case, this does not seem to be an InnoDB bug.

            marko Marko Mäkelä added a comment - Based on the trace that I analyzed, this looks like a buffer overflow: 10.6 ba4541ba7f0d89e7825f1dae44eb96142b25138b 0x00000000007c5395 in __asan_memcpy () 1: x/i $pc => 0x7c5395 <__asan_memcpy+117>: lea (%r15,%rbx,1),%rax (rr) i reg rbx rbx 0x402 1026 (rr) bt #0 0x00000000007c5395 in __asan_memcpy () #1 0x0000000000ec12e4 in TABLE::init (this=0x619000064598, thd=<optimized out>, tl=<optimized out>) at table.cc:5787 #2 0x0000000000981d25 in open_table (thd=<optimized out>, table_list=0x62b0000a1938, ot_ctx=0x2b3f63301160) at sql_base.cc:2175 #3 0x000000000098b7f9 in open_and_process_table (thd=0x62b00009a218, tables=0x62b0000a1938, counter=0x2b3f633014c0, flags=0, prelocking_strategy=0x2b3f633015e0, ot_ctx=0x2b3f63301160, has_prelocking_list=<optimized out>) at sql_base.cc:3877 #4 open_tables (thd=<optimized out>, options=<optimized out>, start=<optimized out>, counter=<optimized out>, flags=<optimized out>, prelocking_strategy=<optimized out>) at sql_base.cc:4361 #5 0x000000000099518e in open_and_lock_tables (thd=<optimized out>, options=<optimized out>, tables=<optimized out>, derived=<optimized out>, flags=<optimized out>, prelocking_strategy=<optimized out>) at sql_base.cc:5333 #6 0x0000000000b4186b in open_and_lock_tables (thd=0x62b00009a218, tables=0x62b0000a1938, derived=255, flags=0) at sql_base.h:515 #7 execute_sqlcom_select (thd=0x62b00009a218, all_tables=<optimized out>) at sql_parse.cc:6328 #8 0x0000000000b3002f in mysql_execute_command (thd=0x62b00009a218, is_called_from_prepared_stmt=<optimized out>) at sql_parse.cc:3999 #9 0x0000000000b1be41 in mysql_parse (thd=0x62b00009a218, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at sql_parse.cc:8194 #10 0x0000000000b15b01 in dispatch_command (command=<optimized out>, thd=0x62b00009a218, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at sql_parse.cc:1908 #11 0x0000000000b1cb1a in do_command (thd=0x62b00009a218, blocking=true) at sql_parse.cc:1421 #12 0x0000000000f78185 in do_handle_one_connection (connect=<optimized out>, put_in_cache=<optimized out>) at sql_connect.cc:1407 #13 0x0000000000f778ac in handle_one_connection (arg=0x608000002d38) at sql_connect.cc:1319 #14 0x00001500733dc609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #15 0x00001e044af8a353 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Here, the length seems to be 1026 bytes. But, a little before the assertion failure: 10.6 ba4541ba7f0d89e7825f1dae44eb96142b25138b #0 0x00000000007c8440 in __asan_region_is_poisoned () #1 0x00000000020f0d56 in row_sel_field_store_in_mysql_format_func (dest=0x61d0000532b9 "", templ=0x60d000010030, data=0x66466b994092 "1", len=1) at row/row0sel.cc:2809 #2 0x00000000021140a9 in row_sel_store_mysql_field (mysql_rec=<optimized out>, prebuilt=<optimized out>, rec=<optimized out>, index=<optimized out>, offsets=0x2b3f632ffee0, field_no=3, templ=<optimized out>) at row/row0sel.cc:3101 #3 0x00000000021033f7 in row_sel_store_mysql_rec (mysql_rec=0x61d0000532b8 "\377", prebuilt=0x403, rec=0x66466b99407f "", vrow=<optimized out>, rec_clust=false, index=0x616000032df0, offsets=0x2b3f632ffee0) at row/row0sel.cc:3237 … (rr) frame 1 #1 0x00000000020f0d56 in row_sel_field_store_in_mysql_format_func (dest=0x61d0000532b9 "", templ=0x60d000010030, data=0x66466b994092 "1", len=1) at row/row0sel.cc:2809 2809 MEM_CHECK_ADDRESSABLE(dest, templ->mysql_col_len); (rr) print *templ $4 = {col_no = 0, rec_field_no = 3, rec_field_is_prefix = 0, rec_prefix_field_no = 18446744073709551615, clust_rec_field_no = 3, icp_rec_field_no = 13744632839234567870, mysql_col_offset = 1, mysql_col_len = 1027, mysql_null_byte_offset = 0, mysql_null_bit_mask = 1, type = 12, mysql_type = 15, mysql_length_bytes = 2, charset = 17, mbminlen = 1, mbmaxlen = 5, is_unsigned = 0, is_virtual = 0} we can see that we are trying to access 1027=2+5*205 bytes within something that is at most 1026 bytes long. I assume that the 2 bytes are for storing the length of the VARCHAR column. In the filename character set, each source character occupies 1, 3, or 5 ASCII characters per source character. A long enough CHAR column will be treated as VARCHAR . In any case, this does not seem to be an InnoDB bug.

            This issue was/is also present in 10.5:

            CS 10.5.28 cf2d49ddcfdb158e46dcd9cc575c54205b5eef50 (Debug, UBASAN)

            10.5.28-dbg>SET sql_mode='';
            Query OK, 0 rows affected (0.001 sec)
             
            10.5.28-dbg>CREATE TABLE t (a CHAR(205)) ENGINE=INNODB CHARACTER SET filename;
            Query OK, 0 rows affected, 1 warning (0.020 sec)
             
            10.5.28-dbg>INSERT INTO t VALUES (1);
            Query OK, 1 row affected (0.006 sec)
             
            10.5.28-dbg>SELECT * FROM t;
            ERROR 2013 (HY000): Lost connection to MySQL server during query
            

            CS 10.5.28 cf2d49ddcfdb158e46dcd9cc575c54205b5eef50 (Debug, UBASAN)

            mariadbd: /test/10.5_dbg_san/storage/innobase/row/row0sel.cc:2753: void row_sel_field_store_in_mysql_format_func(byte*, const mysql_row_templ_t*, const dict_index_t*, ulint, const byte*, ulint): Assertion `!__asan_region_is_poisoned((void*) dest,templ->mysql_col_len)' failed.
            

            See MDEV-35490.

            Roel Roel Van de Paar added a comment - This issue was/is also present in 10.5: CS 10.5.28 cf2d49ddcfdb158e46dcd9cc575c54205b5eef50 (Debug, UBASAN) 10.5.28-dbg>SET sql_mode=''; Query OK, 0 rows affected (0.001 sec)   10.5.28-dbg>CREATE TABLE t (a CHAR(205)) ENGINE=INNODB CHARACTER SET filename; Query OK, 0 rows affected, 1 warning (0.020 sec)   10.5.28-dbg>INSERT INTO t VALUES (1); Query OK, 1 row affected (0.006 sec)   10.5.28-dbg>SELECT * FROM t; ERROR 2013 (HY000): Lost connection to MySQL server during query CS 10.5.28 cf2d49ddcfdb158e46dcd9cc575c54205b5eef50 (Debug, UBASAN) mariadbd: /test/10.5_dbg_san/storage/innobase/row/row0sel.cc:2753: void row_sel_field_store_in_mysql_format_func(byte*, const mysql_row_templ_t*, const dict_index_t*, ulint, const byte*, ulint): Assertion `!__asan_region_is_poisoned((void*) dest,templ->mysql_col_len)' failed. See MDEV-35490 .

            People

              bar Alexander Barkov
              ramesh Ramesh Sivaraman
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.