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 :| _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
