MDEV-34502 InnoDB debug mode build - asserts with Valgrind #3378
Conversation
Valgrind looks as the assertions as examining uninitalized values. As the assertions are tested in other Debug builds we know it isn't all invalid. Account for Valgrind by removing the assertion under the WITH_VALGRIND=1 compulation.
grooverdan
added
the
MariaDB Foundation
There was a problem hiding this comment.
Looks like, for these paths we have a nibble (half of the byte) of the last byte of variable n uninitialized. In the debug assert (& ~0xFFUL) and (n & ~0xFFFFU) should clear out the last byte so there is no issue in the debug assert but this is possibly the reason that valgrind is confused. In actual record the other parts are initialized later.
Although, it doesn't look very good adding these exception I guess it is ok for this case. I don't see how else we can address it. Zero Initializing the whole record after allocation may introduce performance regression as it is quite frequently used path.
Thanks for the patch. Please go ahead.
Is negated *~*0xFFFFU, so it clears, all except the last uninitialized byte. Technically it does read the uninit value, it just doesn't make such sense to report this as an error as the assertion purpose is to detect this. Technically valgrind can't tell the purpose of an |
Description
\Valgrind looks at the assertions as examining uninitialized values.
As the assertions are tested in other Debug builds we know it isn't all invalid.
Account for Valgrind by removing the assertion under the WITH_VALGRIND=1 compilation.
Release Notes
N/A
How can this PR be tested?
Valgrind builder with newer 3.23.0 version run leaktest like:
mysql-test/mysql-test-run.pl --valgrind="--leak-check=summary --gen-suppressions=yes --num-callers=10" innodb.alter_not_null
If the changes are not amenable to automated testing, please explain why not and carefully describe how to test manually.
Basing the PR against the correct MariaDB version
PR quality check