mirror of
https://github.com/MariaDB/server.git
synced 2025-01-16 03:52:35 +01:00
6487b8e330
In case when filesort does not use addon field packing (because of too small potential savings) and uses fixed width addon fields instead, the field->pack() call can store less bytes when the field maximum possible field length, e.g. in case of VARCHAR(). The memory between the packed length and addonf->length (the maximum length) stayed uninitialized, which was reported by Valgrind/MSAN. The problem was introduced byf52bf92014in 10.5, which removed the tail initialization (probably unintentionally). Restoring the bzero() in the fixed length branch, so in case when pack() stores less bytes than addonf->length says, the trailing bytes gets initialized. Note, beforef52bf92014, the bzero() was under HAVE_valgrind conditional compilation. Now it's being added unconditionally: - MSAN also reported the problem, so it's not only Valgrind specific. - As Serg proposed, conditional initialization is bad - it can have potentional security problems as the non-initialized memory fragments can store various pieces of essential information, e.g. passwords.
29 lines
626 B
Text
29 lines
626 B
Text
#
|
|
# Start of 10.5 tests
|
|
#
|
|
#
|
|
# MDEV-27307 main.ctype_utf8mb4_uca_allkeys tests fail with Valgrind/MSAN
|
|
#
|
|
# In this scenario packing is fully disabled:
|
|
# - The sortkey is of a fixed width data type
|
|
# - The addon fields have too small potential savings
|
|
SET NAMES latin1;
|
|
CREATE TABLE t1 (
|
|
code INT NOT NULL,
|
|
str VARCHAR(5) CHARACTER SET latin1 NOT NULL
|
|
) ENGINE=MyISAM;
|
|
FOR i IN 0..50
|
|
DO
|
|
INSERT INTO t1 VALUES (i, REPEAT('a',1));
|
|
END FOR;
|
|
$$
|
|
SELECT COUNT(*) FROM t1;
|
|
COUNT(*)
|
|
51
|
|
SET sort_buffer_size=1024;
|
|
SELECT HEX(code), HEX(str) FROM t1 ORDER BY HEX(str);
|
|
SET sort_buffer_size=DEFAULT;
|
|
DROP TABLE t1;
|
|
#
|
|
# End of 10.5 tests
|
|
#
|