[MDEV-24066] ASAN unknown-crash in hp_rec_hashnr after replace into partition +invisible columns and runtime error: load of value 25264, which is not a valid value for type 'geometry_type' in make_empty_rec Created: 2020-10-30  Updated: 2022-10-13  Resolved: 2022-10-13

Status: Closed
Project: MariaDB Server
Component/s: Partitioning
Affects Version/s: 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Alice Sherepa Assignee: Sergei Golubchik
Resolution: Won't Fix Votes: 0
Labels: corruption

Issue Links:
Relates
relates to MDEV-24070 ASAN : unknown-crash after replace in... Open
relates to MDEV-29052 SIGSEGV's in hp_rec_hashnr and my_has... Closed
relates to MDEV-28346 UBSAN: runtime error: downcast of add... Confirmed

 Description   

--source include/have_partition.inc
 
CREATE  TABLE  t1 (i1 int, i2 int NOT NULL, KEY (i2)) ENGINE = MEMORY;
 
SET  debug_dbug="+d,test_completely_invisible";
ALTER  TABLE t1 PARTITION BY RANGE (i1) (PARTITION p0 VALUES LESS THAN (100), PARTITION p1 VALUES LESS THAN MAXVALUE);
 
SET  debug_dbug="";
ALTER  TABLE t1 DROP PARTITION p1;
REPLACE  INTO t1  PARTITION (p0)  (i1, i2) VALUES (8, 8), (2, 8);

10.3 14d43f4fa691e3af113195a3

Version: '10.3.26-MariaDB-debug-log'  socket: '/git/10.3/mysql-test/var/tmp/mysqld.1.sock'  port: 16000  Source distribution
=================================================================
==2649==ERROR: AddressSanitizer: unknown-crash on address 0x61900008f841 at pc 0x55dad3adb3ab bp 0x7f64529d59c0 sp 0x7f64529d59b8
READ of size 1 at 0x61900008f841 thread T5
    #0 0x55dad3adb3aa in hp_rec_hashnr /git/10.3/storage/heap/hp_hash.c:341
    #1 0x55dad3aeaf29 in hp_write_key /git/10.3/storage/heap/hp_write.c:349
    #2 0x55dad3ae90a1 in heap_write /git/10.3/storage/heap/hp_write.c:52
    #3 0x55dad3ad093c in ha_heap::write_row(unsigned char*) /git/10.3/storage/heap/ha_heap.cc:235
    #4 0x55dad358c2a9 in handler::ha_write_row(unsigned char*) /git/10.3/sql/handler.cc:6467
    #5 0x55dad4952598 in ha_partition::write_row(unsigned char*) /git/10.3/sql/ha_partition.cc:4343
    #6 0x55dad358c173 in handler::ha_write_row(unsigned char*) /git/10.3/sql/handler.cc:6467
    #7 0x55dad2d158e6 in write_record(THD*, TABLE*, st_copy_info*) /git/10.3/sql/sql_insert.cc:1712
    #8 0x55dad2d10468 in mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool) /git/10.3/sql/sql_insert.cc:1072
    #9 0x55dad2dbc149 in mysql_execute_command(THD*) /git/10.3/sql/sql_parse.cc:4450
    #10 0x55dad2dd4b44 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /git/10.3/sql/sql_parse.cc:7811
    #11 0x55dad2dab472 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /git/10.3/sql/sql_parse.cc:1851
    #12 0x55dad2da7bad in do_command(THD*) /git/10.3/sql/sql_parse.cc:1397
    #13 0x55dad31971d6 in do_handle_one_connection(CONNECT*) /git/10.3/sql/sql_connect.cc:1403
    #14 0x55dad3196a8e in handle_one_connection /git/10.3/sql/sql_connect.cc:1308
    #15 0x55dad48f8e18 in pfs_spawn_thread /git/10.3/storage/perfschema/pfs.cc:1869
    #16 0x7f645d2cdfa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486
    #17 0x7f645cc514ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce)
 
0x61900008f841 is located 193 bytes inside of 1100-byte region [0x61900008f780,0x61900008fbcc)
allocated by thread T5 here:
    #0 0x7f645d3d0330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x55dad4b0d5cb in sf_malloc /git/10.3/mysys/safemalloc.c:118
    #2 0x55dad4adcb05 in my_malloc /git/10.3/mysys/my_malloc.c:101
    #3 0x55dad4ab986a in alloc_root /git/10.3/mysys/my_alloc.c:251
    #4 0x55dad4abaf8a in strmake_root /git/10.3/mysys/my_alloc.c:481
    #5 0x55dad30c15c3 in open_table_from_share(THD*, TABLE_SHARE*, st_mysql_const_lex_string const*, unsigned int, unsigned int, unsigned int, TABLE*, bool, List<String>*) /git/10.3/sql/table.cc:3230
    #6 0x55dad2c36faf in open_table(THD*, TABLE_LIST*, Open_table_context*) /git/10.3/sql/sql_base.cc:1992
    #7 0x55dad2c403e3 in open_and_process_table /git/10.3/sql/sql_base.cc:3730
    #8 0x55dad2c42cb1 in open_tables(THD*, DDL_options_st const&, TABLE_LIST**, unsigned int*, unsigned int, Prelocking_strategy*) /git/10.3/sql/sql_base.cc:4199
    #9 0x55dad2c48766 in open_and_lock_tables(THD*, DDL_options_st const&, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*) /git/10.3/sql/sql_base.cc:5096
    #10 0x55dad2ba23f4 in open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int) /git/10.3/sql/sql_base.h:503
    #11 0x55dad2d0db20 in mysql_insert(THD*, TABLE_LIST*, List<Item>&, List<List<Item> >&, List<Item>&, List<Item>&, enum_duplicates, bool) /git/10.3/sql/sql_insert.cc:760
    #12 0x55dad2dbc149 in mysql_execute_command(THD*) /git/10.3/sql/sql_parse.cc:4450
    #13 0x55dad2dd4b44 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /git/10.3/sql/sql_parse.cc:7811
    #14 0x55dad2dab472 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /git/10.3/sql/sql_parse.cc:1851
    #15 0x55dad2da7bad in do_command(THD*) /git/10.3/sql/sql_parse.cc:1397
    #16 0x55dad31971d6 in do_handle_one_connection(CONNECT*) /git/10.3/sql/sql_connect.cc:1403
    #17 0x55dad3196a8e in handle_one_connection /git/10.3/sql/sql_connect.cc:1308
    #18 0x55dad48f8e18 in pfs_spawn_thread /git/10.3/storage/perfschema/pfs.cc:1869
    #19 0x7f645d2cdfa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486
 
Thread T5 created by T0 here:
    #0 0x7f645d337db0 in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x50db0)
    #1 0x55dad48f9254 in spawn_thread_v1 /git/10.3/storage/perfschema/pfs.cc:1919
    #2 0x55dad2abb6f4 in inline_mysql_thread_create /git/10.3/include/mysql/psi/mysql_thread.h:1275
    #3 0x55dad2ad4ba8 in create_thread_to_handle_connection(CONNECT*) /git/10.3/sql/mysqld.cc:6609
    #4 0x55dad2ad52fd in create_new_thread /git/10.3/sql/mysqld.cc:6679
    #5 0x55dad2ad647e in handle_connections_sockets() /git/10.3/sql/mysqld.cc:6937
    #6 0x55dad2ad3f1c in mysqld_main(int, char**) /git/10.3/sql/mysqld.cc:6231
    #7 0x55dad2ab9df4 in main /git/10.3/sql/main.cc:25
    #8 0x7f645cb7c09a in __libc_start_main ../csu/libc-start.c:308
 
SUMMARY: AddressSanitizer: unknown-crash /git/10.3/storage/heap/hp_hash.c:341 in hp_rec_hashnr
Shadow bytes around the buggy address:
  0x0c3280009eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c3280009ec0: 00 00 00 f7 00 03 f7 04 f7 f7 f7 f7 f7 f7 f7 f7
  0x0c3280009ed0: f7 f7 f7 f7 f7 f7 f7 f7 f7 04 fa fa fa fa fa fa
  0x0c3280009ee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3280009ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c3280009f00: 00 f7 03 f7 00 00 f7 00[01]00 01 f7 00 00 00 f7
  0x0c3280009f10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c3280009f20: 00 00 00 00 00 00 00 00 00 00 00 f7 00 00 00 00
  0x0c3280009f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c3280009f40: 00 00 00 00 00 00 00 f7 00 00 00 00 00 00 00 00
  0x0c3280009f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==2649==ABORTING
----------SERVER LOG END-------------
 
 



 Comments   
Comment by Roel Van de Paar [ 2022-07-07 ]

Confirmed.

CREATE TABLE t1 (i1 INT, i2 INT NOT NULL, KEY(i2)) ENGINE=MEMORY;
SET debug_dbug="+d,test_completely_invisible";
ALTER TABLE t1 PARTITION BY RANGE (i1) (PARTITION p0 VALUES LESS THAN (100), PARTITION p1 VALUES LESS THAN MAXVALUE);
SET debug_dbug="";
ALTER TABLE t1 DROP PARTITION p1;
REPLACE INTO t1 PARTITION (p0) (i1, i2) VALUES (8, 8),(2, 8);

Leads to:

10.4.25 b2ecb622a6d11df4f670041fbd7f48fe4077808a (Debug)

==2018316==ERROR: AddressSanitizer: unknown-crash on address 0x6190000a5641 at pc 0x55b36b8c3a8f bp 0x151fb83644c0 sp 0x151fb83644b0

Setup:

Compiled with GCC >=7.5.0 (I use GCC 9.4.0) and:
    -DWITH_ASAN=ON -DWITH_ASAN_SCOPE=ON -DWITH_UBSAN=ON -DWITH_RAPID=OFF -DWSREP_LIB_WITH_ASAN=ON
Set before execution:
    export ASAN_OPTIONS=quarantine_size_mb=512:atexit=1:detect_invalid_pointer_pairs=3:dump_instruction_bytes=1:abort_on_error=1
    export UBSAN_OPTIONS=print_stacktrace=1

Bug confirmed present in:
MariaDB: 10.3.35 (dbg), 10.4.25 (dbg), 10.5.16 (dbg), 10.6.8 (dbg), 10.7.4 (dbg), 10.8.3 (dbg), 10.9.0 (dbg)

Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.3.35 (opt), 10.4.25 (opt), 10.5.16 (opt), 10.6.8 (opt), 10.7.4 (opt), 10.8.3 (opt), 10.9.0 (opt)

Comment by Roel Van de Paar [ 2022-07-07 ]

See MDEV-29052 info

Comment by Roel Van de Paar [ 2022-07-07 ]

If you swap the storage engine to InnoDB, the table corrupts on the final query:

10.10.0 63961a08a6203f4d58363a9321e4cf9c8b07a9fe (Debug)

10.10.0-dbg>REPLACE INTO t1 PARTITION (p0) (i1, i2) VALUES (8, 8),(2, 8);
ERROR 1194 (HY000): Table 't1' is marked as crashed and should be repaired

marko FYI

Comment by Roel Van de Paar [ 2022-07-07 ]

On 10.3 debug only, with the testcase as given, this UBSAN issue is seen before the crash:

10.3.35 3814b04d6b0b87e20cdfa85933221d463ce71515 (Debug, UBASAN)

Version: '10.3.35-MariaDB-debug'  socket: '/test/UBASAN_MD090422-mariadb-10.3.35-linux-x86_64-dbg/socket.sock'  port: 10179  MariaDB Server
/test/10.3_dbg_san/sql/unireg.cc:1067:32: runtime error: load of value 25264, which is not a valid value for type 'geometry_type'
    #0 0x5648c8c8e413 in make_empty_rec /test/10.3_dbg_san/sql/unireg.cc:1067
    #1 0x5648c8c8e413 in build_frm_image(THD*, st_mysql_const_lex_string const*, HA_CREATE_INFO*, List<Create_field>&, unsigned int, st_key*, handler*) /test/10.3_dbg_san/sql/unireg.cc:394
    #2 0x5648c8ab4e40 in mysql_create_frm_image(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, HA_CREATE_INFO*, Alter_info*, int, st_key**, unsigned int*, st_mysql_const_unsigned_lex_string*) /test/10.3_dbg_san/sql/sql_table.cc:4869
    #3 0x5648c8ae01ff in create_table_impl /test/10.3_dbg_san/sql/sql_table.cc:5111
    #4 0x5648c8afe8df in mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool) /test/10.3_dbg_san/sql/sql_table.cc:9972
    #5 0x5648c8d8b3a3 in Sql_cmd_alter_table::execute(THD*) /test/10.3_dbg_san/sql/sql_alter.cc:512
    #6 0x5648c8699561 in mysql_execute_command(THD*) /test/10.3_dbg_san/sql/sql_parse.cc:6075
    #7 0x5648c86a118d in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /test/10.3_dbg_san/sql/sql_parse.cc:7870
    #8 0x5648c86aca53 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /test/10.3_dbg_san/sql/sql_parse.cc:1852
    #9 0x5648c86bab35 in do_command(THD*) /test/10.3_dbg_san/sql/sql_parse.cc:1398
    #10 0x5648c8d74ce1 in do_handle_one_connection(CONNECT*) /test/10.3_dbg_san/sql/sql_connect.cc:1403
    #11 0x5648c8d757f3 in handle_one_connection /test/10.3_dbg_san/sql/sql_connect.cc:1308
    #12 0x150147b65608 in start_thread /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_create.c:477
    #13 0x15014711d132 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x11f132)

Comment by Nayuta Yanagisawa (Inactive) [ 2022-07-08 ]

The issue is possibly related to MDEV-15167.

Comment by Sergei Golubchik [ 2022-10-13 ]

"test_completely_invisible" is a dbug keyword, it's supposed to be used in a very specific way.
In particular, it's wrong to enable it for one ALTER TABLE and then disable for another ALTER TABLE.

Because it auto-adds a "fully invisible" column to the table. Any ALTER TABLE skips such columns, so they have to be auto-added again, in every ALTER. Otherwise frm and the actual table structure go out of sync, because frm loses this column, but underlying tables aren't rebuilt

Generated at Thu Feb 08 09:27:10 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.