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