Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.5, 10.3(EOL), 10.4(EOL)
Description
Based on a trace that I analyzed in MDEV-22924, I created the following test case:
--source include/have_innodb.inc
|
CREATE TABLE t1(a INT PRIMARY KEY, b INT, g INT GENERATED ALWAYS AS(b)VIRTUAL) |
ENGINE=InnoDB;
|
INSERT INTO t1 VALUES (1,1,default); |
ALTER TABLE t1 ADD COLUMN c INT; |
ALTER TABLE t1 ADD KEY(g); |
CHECK TABLE t1; |
SELECT g FROM t1 FORCE INDEX (g); |
DROP TABLE t1; |
This test will fail in 10.3 Valgrind as well as 10.5 MSAN:
10.3 6a042281bdbfe91cc39e1f6e02295bfe7eaa9d43 |
==469741== Uninitialised byte(s) found during client check request
|
==469741== at 0xD23BEE: dfield_dup (data0data.ic:172)
|
==469741== by 0xD23BEE: row_merge_buf_add(row_merge_buf_t*, dict_index_t*, dict_table_t const*, dict_table_t const*, fts_psort_t*, dtuple_t*, row_ext_t const*, unsigned long*, mem_block_info_t*, dberr_t*, mem_block_info_t**, TABLE*, trx_t*) (row0merge.cc:841)
|
==469741== by 0xD26DC2: row_merge_read_clustered_index(trx_t*, TABLE*, dict_table_t const*, dict_table_t*, bool, dict_index_t**, dict_index_t*, fts_psort_t*, merge_file_t*, unsigned long const*, unsigned long, dtuple_t const*, dict_add_v_col_t const*, unsigned long const*, unsigned long, ib_sequence_t&, unsigned char*, bool, pfs_os_file_t*, ut_stage_alter_t*, double, unsigned char*, TABLE*, bool) (row0merge.cc:2358)
|
10.5 31e6c96b0449761dc15f548c28ded671d1b7219b |
Uninitialized bytes in __msan_check_mem_is_initialized at offset 0 inside [0x7290000b90f0, 4)
|
==457772==WARNING: MemorySanitizer: use-of-uninitialized-value
|
#0 0x55a19150c8f0 in dfield_dup(dfield_t*, mem_block_info_t*) /mariadb/10.5m/storage/innobase/include/data0data.ic:169:3
|
#1 0x55a19150c8f0 in row_merge_buf_add(row_merge_buf_t*, dict_index_t*, dict_table_t const*, dict_table_t const*, fts_psort_t*, dtuple_t*, row_ext_t const*, unsigned long*, mem_block_info_t*, dberr_t*, mem_block_info_t**, TABLE*, trx_t*) /mariadb/10.5m/storage/innobase/row/row0merge.cc:835:3
|
If the ADD COLUMN is removed or ,FORCE is added to the statement, the test will not fail. Instant ADD COLUMN was introduced in MDEV-11369.
Attachments
Issue Links
- relates to
-
MDEV-24564 Statistics are lost after ALTER TABLE
- Closed
-
MDEV-25509 Atomic DDL: Assertion `err != DB_DUPLICATE_KEY' fails after previous error upon multi-RENAME
- Closed
-
MDEV-5800 indexes on virtual (not materialized) columns
- Closed
-
MDEV-11369 Instant add column for InnoDB
- Closed
-
MDEV-22924 Warning InnoDB: Index 'Marvão_idx3' contains 36 entries, should be 37.
- Closed