Potential SIGSEGV in Replicator

[ankur-anand]

There is a potential test of conditional scenarios where a sigsegv could happen.

1. Replicator reads a batch of records. The walfs reader returns slices pointing directly to the memory-mapped file.
2. Replicator sends this batch to the GrpcStreamer via a buffered channel.
3. Replicator continues its loop, calls reader.Next(), and hits io.EOF.
4. Replicator immediately calls reader.Close().
5. This decrements the reference count on the underlying Segment.

If the segment was marked for deletion (e.g., it was rotated and is old), the reference count dropping to zero triggers Segment.cleanup(), which unmaps the memory.
Streamer (running in a separate goroutine) picks up the batch from the channel and tries to marshal the data for gRPC.

The simple fix would be copy the data from the mmap-ed slice into a new slice before adding it to the batch.

[gamerioo]

HEY @ankur-anand ,I'm fairly new to the codebase and opensource in general however i spent some time digging into the issue (thanks to your clear description) the way i see it ,crash might happen because the streamer goroutine can try to read data that's already been unmapped , the reader gives back a slice that points straight into the mmap'd file, and if reader.Close() runs before the streamer gets to that data, the memory is gone . My fix : just copy the bytes out of the mmap slice into a new heap allocated slice before putting it into the channel. That way the streamer always has its own copy and it doesn't matter when the reader closes or the segment gets cleaned up. If you're fine with this should i open a PR , Regards

[ankur-anand]

@gamerioo Yes, the approach is correct!