[MDEV-28370] ASAN failure: InnoDB fails to free the memory allocated on dict_load_indexes() Created: 2022-04-20  Updated: 2022-09-14  Resolved: 2022-04-21

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.6
Fix Version/s: 10.6.8

Type: Bug Priority: Major
Reporter: Thirunarayanan Balathandayuthapani Assignee: Thirunarayanan Balathandayuthapani
Resolution: Fixed Votes: 0
Labels: None


 Description   

The following test case fails on 10.6:

--source include/have_innodb.inc
--echo #
--echo # MDEV-26936 Recovery crash on rolling back DELETE FROM SYS_INDEXES
--echo #
 
CREATE TABLE t1(a INT PRIMARY KEY, b INT) ENGINE=InnoDB;
INSERT INTO t1 VALUES(1,1);
 
connect ddl, localhost, root;
SET DEBUG_SYNC = 'row_merge_after_scan SIGNAL scanned WAIT_FOR commit';
SET DEBUG_SYNC = 'before_commit_rollback_inplace SIGNAL c WAIT_FOR ever';
send ALTER TABLE t1 ADD UNIQUE INDEX(b), ALGORITHM=INPLACE;
 
connection default;
SET DEBUG_SYNC = 'now WAIT_FOR scanned';
BEGIN;
INSERT INTO t1 VALUES(2,1);
COMMIT;
SET DEBUG_SYNC = 'now SIGNAL commit';
SET DEBUG_SYNC = 'now WAIT_FOR c';
# Make all pending changes durable for recovery.
SET GLOBAL innodb_fil_make_page_dirty_debug=0;
 
--source include/kill_mysqld.inc
disconnect ddl;
--source include/start_mysqld.inc
 
CHECK TABLE t1;
SHOW CREATE TABLE t1;
SELECT * FROM t1;
DROP TABLE t1;

The failure is

=================================================================
==11000==ERROR: LeakSanitizer: detected memory leaks
 
Indirect leak of 1336 byte(s) in 1 object(s) allocated from:
    #0 0x7f826ca0bf48 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10bf48)
    #1 0x5585b4e75474 in ut_allocator<unsigned char, true>::allocate(unsigned long, unsigned char const*, unsigned int, bool, bool) /home/thiru/mariarepo/10.6/10.6-sample/storage/innobase/include/ut0new.h:375
    #2 0x5585b5057f43 in mem_heap_create_block_func(mem_block_info_t*, unsigned long, char const*, unsigned int, unsigned long) /home/thiru/mariarepo/10.6/10.6-sample/storage/innobase/mem/mem0mem.cc:277
    #3 0x5585b5058895 in mem_heap_add_block(mem_block_info_t*, unsigned long) /home/thiru/mariarepo/10.6/10.6-sample/storage/innobase/mem/mem0mem.cc:378
    #4 0x5585b54cb35d in mem_heap_alloc /home/thiru/mariarepo/10.6/10.6-sample/storage/innobase/include/mem0mem.inl:193
    #5 0x5585b54cbab0 in dict_mem_fill_index_struct /home/thiru/mariarepo/10.6/10.6-sample/storage/innobase/include/dict0mem.inl:49
    #6 0x5585b54d2179 in dict_mem_index_create(dict_table_t*, char const*, unsigned long, unsigned long) /home/thiru/mariarepo/10.6/10.6-sample/storage/innobase/dict/dict0mem.cc:773
    #7 0x5585b54be593 in dict_load_index_low /home/thiru/mariarepo/10.6/10.6-sample/storage/innobase/dict/dict0load.cc:1899
    #8 0x5585b54bf25c in dict_load_indexes /home/thiru/mariarepo/10.6/10.6-sample/storage/innobase/dict/dict0load.cc:1986
    #9 0x5585b54c3a4c in dict_load_table_one /home/thiru/mariarepo/10.6/10.6-sample/storage/innobase/dict/dict0load.cc:2403
    #10 0x5585b54c51b6 in dict_sys_t::load_table(st_::span<char const> const&, dict_err_ignore_t) /home/thiru/mariarepo/10.6/10.6-sample/storage/innobase/dict/dict0load.cc:2527
    #11 0x5585b548ac26 in dict_table_open_on_name(char const*, bool, dict_err_ignore_t) /home/thiru/mariarepo/10.6/10.6-sample/storage/innobase/dict/dict0dict.cc:1081
    #12 0x5585b4dfb388 in innodb_check_version /home/thiru/mariarepo/10.6/10.6-sample/storage/innobase/handler/ha_innodb.cc:2043
    #13 0x5585b3ea09b5 in ddl_log_execute_action /home/thiru/mariarepo/10.6/10.6-sample/sql/ddl_log.cc:2030
    #14 0x5585b3ea30e9 in ddl_log_execute_entry_no_lock /home/thiru/mariarepo/10.6/10.6-sample/sql/ddl_log.cc:2411
    #15 0x5585b3ea5425 in ddl_log_execute_recovery() /home/thiru/mariarepo/10.6/10.6-sample/sql/ddl_log.cc:2772

Problem is that dict_load_indexes() fails to free the index if the system record has
index name TEMP_INDEX_PREFIX_STR, but it ignores the record and move on to next record.



 Comments   
Comment by Marko Mäkelä [ 2022-04-20 ]

OK to push. If possible, please indicate the cause. Could it be MDEV-27234?

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