Libguestfs - Jun 2022 - libnbd golang failure on RISC-V

On Thu, Jun 09, 2022 at 03:08:51PM +0100, Richard W.M. Jones
wrote:
> On Thu, Jun 09, 2022 at 02:14:07PM +0100, Daniel P. Berrang? wrote:
> > 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.
> 
> Eventually careful reading of this page revealed how to do this:
> https://pkg.go.dev/runtime
> 
> The results unfortunately don't seem very useful.  The stack trace
> appears to point to where the error was detected rather than where it
> was caused, but I've copied it below anyway.
> 
> Also attached is the failure in the test suite if you turn *off*
> cgocheck, maybe that is useful.
> -- 
> Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> nbdkit - Flexible, fast NBD server with plugins
> https://gitlab.com/nbdkit/nbdkit
> + requires nbdkit --version
> + go test -count=1 -v
> === RUN   Test010Load
> --- PASS: Test010Load (0.00s)
> === RUN   TestAioBuffer
> --- PASS: TestAioBuffer (0.00s)
> === RUN   TestAioBufferFree
> --- PASS: TestAioBufferFree (0.00s)
> === RUN   TestAioBufferBytesAfterFree
> SIGABRT: abort
> PC=0x3fdf6f9bac m=0 sigcode=18446744073709551610
So suggesting TestAioBufferBytesAfterFree is as fault, but quite
odd as that test case is trivial and whle it allocates some
native memory it doesn't seem to write to it. Unless the problem
happened in an earlier test case and we have delayed detection ?

I guess I'd try throwing darts at the wall by chopping out bits
of test code to see what makes it disappear.

Perhaps also try swapping MakeAioBuffer with MakeAioBufferZero
in case pre-existing data into the C.malloc()d block is confusing
Go ? 

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

On Thu, Jun 09, 2022 at 03:20:02PM +0100, Daniel P. Berrang?
wrote:
> > + go test -count=1 -v
> > === RUN   Test010Load
> > --- PASS: Test010Load (0.00s)
> > === RUN   TestAioBuffer
> > --- PASS: TestAioBuffer (0.00s)
> > === RUN   TestAioBufferFree
> > --- PASS: TestAioBufferFree (0.00s)
> > === RUN   TestAioBufferBytesAfterFree
> > SIGABRT: abort
> > PC=0x3fdf6f9bac m=0 sigcode=18446744073709551610
> 
> So suggesting TestAioBufferBytesAfterFree is as fault, but quite
> odd as that test case is trivial and whle it allocates some
> native memory it doesn't seem to write to it. Unless the problem
> happened in an earlier test case and we have delayed detection ?
> 
> I guess I'd try throwing darts at the wall by chopping out bits
> of test code to see what makes it disappear.
> 
> Perhaps also try swapping MakeAioBuffer with MakeAioBufferZero
> in case pre-existing data into the C.malloc()d block is confusing
> Go ? 
Interestingly if I remove libnbd_020_aio_buffer_test.go completely,
and disable GODEBUG, then the tests pass.  (Reproducer commands at end
of email).  So I guess at least one of the problems is confined to
this test and/or functions it calls in the main library.
Unfortunately this test is huge.

At your suggestion, replacing every MakeAioBuffer with
MakeAioBufferZero in that test, but it didn't help.  Also tried
replacing malloc -> calloc in the aio_buffer.go implementation which
didn't help.

I'll try some more random things ...

Rich.


$ emacs -nw run.in    # comment out GODEBUG line
$ emacs -nw golang/Makefile.am   # remove libnbd_020_aio_buffer_test.go line
$ mv golang/libnbd_020_aio_buffer_test.go golang/libnbd_020_aio_buffer_test.nogo
$ make run
$ make
$ make -C golang check
...
PASS: run-tests.sh
...

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW