Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.4(EOL)
-
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).
Attachments
Issue Links
- relates to
-
MDEV-34625 MariaDB server crashes in 10.11.8 due to using uninitialized member variables
-
- Closed
-
-
MDEV-35494 fil_space_t::fil_space_t() is potentially unsafe with GCC -flifetime-dse
-
- Closed
-
Activity
Field | Original Value | New Value |
---|---|---|
issue.field.resolutiondate | 2019-03-06 09:44:04.0 | 2019-03-06 09:44:04.614 |
Component/s | Storage Engine - XtraDB [ 10135 ] | |
Component/s | Data Definition - Alter Table [ 10114 ] | |
Component/s | Full-text Search [ 10104 ] | |
Fix Version/s | 10.1.39 [ 23305 ] | |
Fix Version/s | 10.2.23 [ 23307 ] | |
Fix Version/s | 10.3.14 [ 23216 ] | |
Fix Version/s | 10.4.4 [ 23310 ] | |
Fix Version/s | 10.4 [ 22408 ] | |
Resolution | Fixed [ 1 ] | |
Status | Open [ 1 ] | Closed [ 6 ] |
Workflow | MariaDB v3 [ 92864 ] | MariaDB v4 [ 155811 ] |
Link |
This issue relates to |
Link |
This issue relates to |
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.