AddressSanitizer:DEADLYSIGNAL in replication.c

[jerrytesting]

Hello, we found one memory issue about DEADLYSIGNAL reported by the AddressSanitizer in version 0.14.0. The following is the bug report:

LIBRAFT   1679628518277105579 src/replication.c:1234 restored snapshot with last index 10821
AddressSanitizer:DEADLYSIGNAL
=================================================================
==187672==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000100 (pc 0x7f0e273aaf31 bp 0x7f0dfa6cfe00 sp 0x7f0dfa6cf5b8 T6)
==187672==The signal is caused by a READ memory access.
==187672==Hint: address points to the zero page.
    #0 0x7f0e273aaf31  /build/glibc-6iIyft/glibc-2.28/string/../sysdeps/x86_64/multiarch/strlen-avx2.S:65

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /build/glibc-6iIyft/glibc-2.28/string/../sysdeps/x86_64/multiarch/strlen-avx2.S:65
Thread T6 created by T0 here:
    #0 0x48cb8c in pthread_create (/opt/fs/dqlite/app+0x48cb8c)
    canonical/raft#1 0x7f0e27661860 in dqlite_node_start /opt/fs/dqlite/src/server.c:712:7
    canonical/raft#2 0x9d08ec in _cgo_a25baf6e879d_Cfunc_dqlite_node_start /tmp/go-build/cgo-gcc-prolog:281:11

==187672==ABORTING

[cole-miller]

Thanks! If you're using a recent version of our Jepsen setup there should be some additional files produced, including a core dump -- do you have those handy? (It would be useful to know the line of code where the segfaulting strlen call occurs.)

[jerrytesting]

Hey, here is the node log and data: https://github.com/jerrytesting/dqlite-memoryIssues/tree/main/DEADLYSIGNAL