Segfault during endpoint write

[jm-positron]

I encountered a segfault during a USB endpoint write.

Unfortunately, I don't have much context beyond the following. In general, my expectation is that gousb should prevent any segfaults by proper management of the underlying connection, but maybe I have a misunderstanding of proper usage of the go package. From a review of the client code for gousb, there is no concurrent access that could potentially cause this.

SIGSEGV: segmentation violation
PC=0x7f6703537c49 m=4 sigcode=128 addr=0x0
signal arrived during cgo execution

goroutine 544 gp=0xc000682e00 m=4 mp=0xc0003ed808 [syscall]:
runtime.cgocall(0xa57cd0, 0xc0023d1548)
	/usr/local/go/src/runtime/cgocall.go:167 +0x4b fp=0xc0023d1520 sp=0xc0023d14e8 pc=0x47c30b
github.com/google/gousb._Cfunc_submit(0x7f66b0004f00)
	_cgo_gotypes.go:680 +0x45 fp=0xc0023d1548 sp=0xc0023d1520 pc=0x8cbb25
github.com/google/gousb.libusbImpl.submit.func1(...)
	/workspaces/my_project/vendor/github.com/google/gousb/libusb.go:470
github.com/google/gousb.libusbImpl.submit({}, 0x7f66b0004f00)
	/workspaces/my_project/vendor/github.com/google/gousb/libusb.go:470 +0x35 fp=0xc0023d1578 sp=0xc0023d1548 pc=0x8ce515
github.com/google/gousb.(*libusbImpl).submit(0xc0041f53b0?, 0x120e500?)
	<autogenerated>:1 +0x25 fp=0xc0023d1590 sp=0xc0023d1578 pc=0x8d1a65
github.com/google/gousb.(*usbTransfer).submit(0xc0041d6740)
	/workspaces/my_project/vendor/github.com/google/gousb/transfer.go:51 +0x90 fp=0xc0023d15e0 sp=0xc0023d1590 pc=0x8c7b90
github.com/google/gousb.(*endpoint).transfer(0xc000822070, {0xcddd20, 0xc0041f53b0}, {0xc0041f6c00, 0x3f7, 0x1?})
	/workspaces/my_project/vendor/github.com/google/gousb/endpoint.go:98 +0xf5 fp=0xc0023d1668 sp=0xc0023d15e0 pc=0x8c6515
github.com/google/gousb.(*OutEndpoint).WriteContext(...)
	/workspaces/my_project/vendor/github.com/google/gousb/endpoint.go:170

Any expertise to help explain what would surface this would be helpful.

[zagrodzki]

Is this a repeatable behavior, or a one-off? If it's repeatable, could you please invoke print_xfer(xfer) inside submit (in transfer.c) before the call to libusb_submit_transfer and share the results.

Please share the client code too, the output of lsusb -v of the device (assuming this is Linux, I'd like to see a list of endpoints and their properties) and what platform this is on.

I've reviewed the code briefly, the only things that I could think of from the top of my head are:

• what happens if you pass an empty buffer. I don't think we handle that explicitly in the code, and I'm not quite sure what happens in the underlying transfer. But I think we just pass down the empty buffer all the way to gousb_alloc_transfer_and_buffer (transfer.c) and I'd expect the transfer to have an empty buffer and a zero length, and I'd assume libusb will handle that correctly.
• for isochronous transfers, if you pass an empty buffer, we might be getting something wrong. I think we set 1 packet of size 0 in the transfer, which sounds like the right thing to do, but I'd need to spend more time looking at the details.

In short, I don't have an obvious answer.

While your assumption is mostly true, that through proper use of libusb APIs we should be ensuring that segmentation faults don't occur, it's not impossible to encounter a segfault even when the code is correct - memory errors, CPU errors, concurrency problems, bugs in libusb, all of that could happen. I don't believe libusb can control all the behavior, but obviously I'd like to make sure we're not making an explicit mistake in our setup of libusb.

[jm-positron]

Appreciate the prompt response, and I'll try to get that debug output on this thread. Not sure about the reproducibility yet, I'll run the test that surfaced this an see how frequent it is.

For my own edification, and for totally clarity, there is no way to recover from this scenario, correct? If we assume there is a bug in libusb or some memory issue we hit, from within the Go process we are hosed. If Go calls out to c and we segfault, the process dies, and we cannot recover, yes?

[zagrodzki]

Correct. On a segmentation fault the state of the memory of the process is unexpected and undefined, and the only reasonable thing to do in that situation is to crash. While it's generally possible to intercept the signal and handle it, I don't believe we have any safe way of recovering.