[Libguestfs] libnbd golang failure on RISC-V

Daniel P. Berrangé berrange at redhat.com
Thu Jun 9 13:14:07 UTC 2022


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 :|


More information about the Libguestfs mailing list