On Thu, Jun 09, 2022 at 02:03:04PM +0100, Richard W.M. Jones
wrote:> make[2]: Entering directory '/home/rjones/d/libnbd/golang'
> perl /home/rjones/d/libnbd/podwrapper.pl --section=3 --man libnbd-golang.3
\
> --html ../html/libnbd-golang.3.html \
> libnbd-golang.pod
> /home/rjones/d/libnbd/run go build
> write of Go pointer 0x3fa8028000 to non-Go memory 0x3fd2c0fb20
> fatal error: Go pointer stored into non-Go memory
>
> runtime stack:
> runtime_mstart
> ../../../libgo/runtime/proc.c:593
>
> goroutine 1 [running, locked to thread]:
>
>
> Not sure how I should diagnose this one further? I wouldn't normally
> worry about RISC-V failures, but they may indicate some kind of arch
> generic problem that is just not exposed on x86.
It could be a bug in the riscv go runtime port, but I think
it is reasonable to consider a latent problem in libnbd code
as these kind of Go/non-Go pointer problems are often
extremely non-deterministic & hard to identify.
Setting GODEBUG=cgocheck=1 or GODEBUG=cgocheck=2 can sometimes
get more info.
If you can get the test to core dump, then plain old GDB core
dump could also be useful - might identify which specific API
is being called, which can help restrict the size of the haystack
for code review.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|