17.02.2023 13:00, PG Bug reporting form wrote:
> The following bug has been logged on the website:
> ...
>
> I've found the following explanation for the failure:
> 1) After the ExecGetUpdateNewTuple() call the newslot and the oldslot are
> linked together (their slot->tts_values[1] in this case point to the same
> memory address (inside the oldslot' buffer)).
> 2) Previously, GetTupleForTrigger() could get a tuple with a new buffer,
> so the oldslot would be the only user of the buffer at that moment.
> (The newslot doesn't become an official user of the buffer.)
> 3) Then, trigtuple = ExecFetchSlotHeapTuple(oldslot, ...) invokes
> tts_buffer_heap_materialize() where the oldslot->buffer is released.
> 4) Finally, newtuple = ExecFetchSlotHeapTuple(newslot, ...) invokes
> tts_buffer_heap_materialize() where an incorrect access to memory
> that became anonymous occurs, and that is detected by valgrind.
> If not detected, different consequences are possible (in the asan case
> it was memcpy with an incorrectly read extra large data_len).
I've tried to materialize newslot before the oldslot materialization
(in ExecFetchSlotHeapTuple(), where their common memory is released),
and it looks like it fixes the issue.
The similar thing done in 75e03eabe.
But I don't know the code good enough so maybe I'm missing something.
Best regards,
Alexander
