[MDEV-18749] rec_get_converted_size_comp_prefix_low: Conditional jump or move depends on uninitialised value upon adding FULLTEXT index Created: 2019-02-26  Updated: 2019-03-12  Resolved: 2019-03-06

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Storage Engine - XtraDB
Affects Version/s: 10.4
Fix Version/s: 10.2.23, 10.1.39, 10.3.14, 10.4.4

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: None


 Description   

--source include/have_innodb.inc
 
CREATE TABLE t1 (c CHAR(255)) ENGINE=InnoDB;
INSERT INTO t1 VALUES ('alternative'),('minds');
ALTER TABLE t1 ADD FULLTEXT INDEX (c);
 
# Cleanup
DROP TABLE t1;

10.4 bb970dda Valgrind

==5989== Thread 29:
==5989== Conditional jump or move depends on uninitialised value(s)
==5989==    at 0x106EF79: unsigned long rec_get_converted_size_comp_prefix_low<false>(dict_index_t const*, dfield_t const*, unsigned long, unsigned long*, rec_comp_status_t, bool) (rem0rec.cc:1191)
==5989==    by 0x106A179: rec_get_converted_size_temp(dict_index_t const*, dfield_t const*, unsigned long, unsigned long*, rec_comp_status_t) (rem0rec.cc:1796)
==5989==    by 0x109F2FC: row_merge_buf_encode(unsigned char**, dict_index_t const*, mtuple_t const*, unsigned long) (row0merge.cc:317)
==5989==    by 0x10A1397: row_merge_buf_write(row_merge_buf_t const*, merge_file_t const*, unsigned char*) (row0merge.cc:1021)
==5989==    by 0x1076905: fts_parallel_tokenization(void*) (row0ftsort.cc:963)
==5989==    by 0x4E3F493: start_thread (pthread_create.c:333)
==5989==    by 0x6A9A93E: clone (clone.S:97)
==5989== Conditional jump or move depends on uninitialised value(s)
==5989==    at 0x106F3AF: unsigned long rec_get_converted_size_comp_prefix_low<false>(dict_index_t const*, dfield_t const*, unsigned long, unsigned long*, rec_comp_status_t, bool) (rem0rec.cc:1235)
==5989==    by 0x106A179: rec_get_converted_size_temp(dict_index_t const*, dfield_t const*, unsigned long, unsigned long*, rec_comp_status_t) (rem0rec.cc:1796)
==5989==    by 0x109F2FC: row_merge_buf_encode(unsigned char**, dict_index_t const*, mtuple_t const*, unsigned long) (row0merge.cc:317)
==5989==    by 0x10A1397: row_merge_buf_write(row_merge_buf_t const*, merge_file_t const*, unsigned char*) (row0merge.cc:1021)
==5989==    by 0x1076905: fts_parallel_tokenization(void*) (row0ftsort.cc:963)
==5989==    by 0x4E3F493: start_thread (pthread_create.c:333)
==5989==    by 0x6A9A93E: clone (clone.S:97)

Not reproducible on 10.3.
Nothing obvious happens on non-valgrind builds (debug, ASAN, relwithdebinfo).



 Comments   
Comment by Marko Mäkelä [ 2019-03-06 ]

The problem is that most of field->col is uninitialized for this index, whose names is tmp_fts_index, created in row_merge_create_fts_sort_index(). The uninitialized bits seem to include field->col->ind, which we are checking in the first part of the debug assertion:

			ut_ad(field->col->is_dropped()
			      || dict_col_type_assert_equal(field->col,
							    &dfield->type));

The fix is simple: row_merge_create_fts_sort_index() should invoke mem_heap_zalloc() instead of mem_heap_alloc() when allocating the 3 copies of field->col. I think that this is best done in 10.1 already, to prevent other potential issues in this area.

Generated at Thu Feb 08 08:46:26 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.