Hi!
>>>>> "Vladimir" == Vladimir Kolesnikov <[email protected]> writes:
Vladimir> Hi Sanja,
Vladimir> I have seen this case before and my analysis showed that the
Vladimir> uninitialized bytes are at the tail of 512-byte blocks. This is not a
Vladimir> bug. This happens because we write data block-by-block and the last
Vladimir> block is likely to be only partially filled with data. If you have
Vladimir> evidence of any real probem with this please let me know, otherwise I
Vladimir> will close the bug.
We would prefer to not have this happen when compiled with HAVE_valgrind.
For example, if we ignore these, we will also miss bugs when you
compile uninitialized bytes into the middle of a block.
For example, in MyISAM we handle it when writing a block:
#ifdef HAVE_valgrind
{
length=mi_getint(buff);
bzero((uchar*) buff+length,keyinfo->block_length-length);
length=keyinfo->block_length;
}
#endif
In other words, we explicitly fill the not used parts with 0 to ensure
that valgrind doesn't complain.
HAVE_valgrind is only defined in debug builds, so there is no speed
penally for production systems.
Regards,
Monty
--
Uninitialised memory write in XTDatabaseLog::xlog_append
https://bugs.launchpad.net/bugs/451080
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
