On 31.05.11 9:22, Stewart Smith wrote:
> On Mon, 30 May 2011 09:15:47 -0000, Alexey Kopytov <email address hidden> wrote:
>> It turns out the bug is not repeatable on a valgrind-enabled build.
>> Going to revert my fix and close the bug as invalid. Will reopen if the
>> bug proves to be repeatable with a valgrind build.
>
> It's been a while for me, but I wonder what the different options are
> for valgrind build? Maybe there is code in there to zero out the row
> buffer (but built only for valgrind builds)?
>
Basically building with compile-pentium-valgrind-max defines HAVE_purify
among other things.
The record buffer did look like zeroed out when examined in a debugger,
but I could not find a quick way to verify that originally, and I didn't
want to spend too much time on it, because I knew the warning was fake.
I have now taken a closer look and found this code right next to the
code allocating the record buffer in sql/table.cc:
#ifdef HAVE_purify
/*
We need this because when we read var-length rows, we are not updating
bytes after end of varchar
*/
if (records > 1)
{
memcpy(outparam->record[0], share->default_values,
share->rec_buff_length);
memcpy(outparam->record[1], share->default_values, share->null_bytes);
if (records > 2)
memcpy(outparam->record[1], share->default_values, share->rec_buff_length);
}
#endif
So yes, it is initialized with default values (which apparently have
zeros for unused bytes in variable-length fields) in valgrind builds.
On 31.05.11 9:22, Stewart Smith wrote:
> On Mon, 30 May 2011 09:15:47 -0000, Alexey Kopytov <email address hidden> wrote:
>> It turns out the bug is not repeatable on a valgrind-enabled build.
>> Going to revert my fix and close the bug as invalid. Will reopen if the
>> bug proves to be repeatable with a valgrind build.
>
> It's been a while for me, but I wonder what the different options are
> for valgrind build? Maybe there is code in there to zero out the row
> buffer (but built only for valgrind builds)?
>
Basically building with compile- pentium- valgrind- max defines HAVE_purify
among other things.
The record buffer did look like zeroed out when examined in a debugger,
but I could not find a quick way to verify that originally, and I didn't
want to spend too much time on it, because I knew the warning was fake.
I have now taken a closer look and found this code right next to the
code allocating the record buffer in sql/table.cc:
#ifdef HAVE_purify outparam- >record[ 0], share-> default_ values, rec_buff_ length) ; outparam- >record[ 1], share-> default_ values, share->null_bytes); outparam- >record[ 1], share-> default_ values,
share- >rec_buff_ length) ;
/*
We need this because when we read var-length rows, we are not updating
bytes after end of varchar
*/
if (records > 1)
{
memcpy(
share->
memcpy(
if (records > 2)
memcpy(
}
#endif
So yes, it is initialized with default values (which apparently have
zeros for unused bytes in variable-length fields) in valgrind builds.