Comment 8 for bug 789131

Revision history for this message
Alexey Kopytov (akopytov) wrote : Re: [Bug 789131] Re: Valgrind warning in MyISAM in mysql-55-eb-blobs

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.