On 2019-12-18 15:41, Anton Lundin wrote:
On 18 December, 2019 - Brendan Horan wrote:
Not sure where to proceed here. I am fairly certain this is not a libdivecomputer bug. Should I log a bug/start a mailing list topic on Subsurface ?
Happy to help out where I can, just not sure where right now.
Something causes LIBUSB_ERROR_BUSY
Usually this indicates another program or driver has already claimed the interface. But in that case, I would expect to get the same error from dctool. But apparently that's not the case. Maybe there is something different in how an appimages run, compared to a "native" application? For example some kind of sandboxing, or other security restrictions?
Note that the LIBUSB_ERROR_BUSY is returned by libusb_claim_interface(). That means the USB device enumeration, and opening the device worked in the appimage.
You could always try to ltrace/strace/systrace subsurface when trying to download to try to figure out the answer.
The easiest way is probably that you build yourself a copy of subsurface from source with debug symbols and just single step into that code trying to figure out whats happening there.
Building subsurface with debug symbols is probably not going to help much, because the error is returned somewhere from inside libusb. You can instead enable debug output from libusb, by setting an environment variable:
export LIBUSB_DEBUG=4 /opt/bin/subsurface -v
Jef