Closed glaubitz closed 9 months ago
Hmm, I was going to take a look, but unfortunately stadler.debian.net
doesn't respond right now :cry:
Hmm, I was going to take a look, but unfortunately
stadler.debian.net
doesn't respond right now 😢
It's up and running, but the IPv6 connection does not work properly. Try ssh -4 stadler.debian.net
to use IPv4-only.
Reproducer with running single test after building:
meson setup c
meson test -C c
gdb --args env LD_LIBRARY_PATH=c LD_PRELOAD=libumockdev-preload.so.0 c/test-umockdev-vala -p /umockdev-testbed-vala/usbfs_ioctl_pcap
Unfortunately the stack trace is absolutely useless:
#0 0xfff80001020259a4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
and so is strace.
This is the only test which fails. If I disable it then everything else succeeds.
I'm actually surprised that this test passes on a lot of architectures -- the pcap file was recorded on x86_64, and there may be some unaligned access there. It's equally possible that some of the buffers allocated in the test are not aligned enough? (but I don't think vala gives you control over this).
Stepping through with gdb it fails in line 580:
assert_cmpint (Posix.ioctl (fd, Ioctl.USBDEVFS_REAPURB, ref urb_reap), CompareOperator.EQ, 0);
The struct usbdevfs_urb is fairly complicated, but /usr/include/linux/usbdevice_fs.h has a matching C declaration, except for void *buffer
→ uint8[] buffer
. I don't know enough about platform specific alignment etc. to know if that is relevant.
So I think the more pressing issue is the FTBFS, so I'll just skip the test on sparc64 for the time being. Actually fixing that requires a compiler expert, and it may even be that pcap files are not platform independent.
Bad timing -- I just released 0.18.0 this morning, but the next release will come at some point :grin:
Hmm, I think in principle the test can be made to work both in big/little endian. But, yes, I think you are right and the pcap code is broken on both big endian and likely also on machines that cannot handle unaligned accesses (which explains the SIGBUS after all).
More specifically, I think the problem are the accesses into usb_header_mmapped
(urb_hdr
in umockdev-pcap.vala
). This data is mmapped and also little endian, but the code just directly reads all those entries.
Note that this code is running in a separate thread. So if you wanted to debug stepping through the test will not narrow it down on that side. I think you need to break on IoctlUsbPcapHandler::handle_ioctl
and step through the code there.
EDIT: Hm, thinking about it, I suspect the mmap'ed data should be correctly aligned. In which case, we probably only fall over due to big/little endian handling.
On Debian unstable running on sparc64, the test
test-umockdev-vala
fails withSIGBUS
:This can easily be reproduced on Debian's new sparc64 porterbox stadler and is also visible in the last build log [1].
Unfortunately, I have no experience with Vala, so I have no idea how to debug this.