On Sat, Feb 15, 2025 at 7:30 AM Melanie Plageman
<melanieplage...@gmail.com> wrote:
> Seems valgrind doesn't like this [1]. I'm looking into it.
Melanie was able to reproduce this on her local valgrind and
eventually we figured out that it's my fault. I put code into
read_stream.c that calls wipe_mem(), thinking that that was our
standard way of scribbling 0x7f on memory that you shouldn't access
again until it's reused. I didn't realise that wipe_mem() also tells
valgrind that the memory is now "no access". That makes sense for
palloc/pfree because when that range is allocated again it'll clear
that. The point is to help people discover that they have a dangling
reference to per-buffer data after they advance to the next buffer,
which wouldn't work because it's in a circular queue and could be
overwritten any time after that.
This fixes it, but is not yet my proposed change:
@@ -193,9 +193,12 @@ read_stream_get_block(ReadStream *stream, void
*per_buffer_data)
if (blocknum != InvalidBlockNumber)
stream->buffered_blocknum = InvalidBlockNumber;
else
+ {
+ VALGRIND_MAKE_MEM_UNDEFINED(per_buffer_data,
stream->per_buffer_data_size);
blocknum = stream->callback(stream,
stream->callback_private_data,
per_buffer_data);
+ }
Thinking about how to make it more symmetrical...
