[prev in list] [next in list] [prev in thread] [next in thread] 

List:       libusb-devel
Subject:    Re: [libusb] Segfault in libusb_free_transfer (artificial use-case)
From:       Xiaofan Chen <xiaofanc () gmail ! com>
Date:       2022-02-03 3:27:15
Message-ID: CAGjSPUATuiYi3qXd-XQMQ16TJmRLNZim7_src2Y-3+XRp5TzKw () mail ! gmail ! com
[Download RAW message or body]

On Tue, Feb 1, 2022 at 9:29 AM Vincent Pelletier <plr.vincent@gmail.com> wrote:
>
> Hello,
>
> I'm working to release a new version of my python wrapper for libusb.
> As a complete coincidence I noticed the 1.0.25 release and ran my tests
> against it. They trigger a segfault in libusb_free_transfer .
>
> Core was generated by `python3 -u -m usb1.testUSB1 -v USBTransferTests.testSetBulk'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x00007fc23097b942 in libusb_free_transfer (transfer=0x1b2e3c8) at io.c:1341
> 1341            usbi_dbg(TRANSFER_CTX(transfer), "transfer %p", transfer);
>
> These tests are rather artificial: in order to not depend on any
> specific usb device being present, they do create USB transfers without
> ever attaching them to any specific device.
> Which means libusb is seeing such call sequence:
>   foo = libusb_alloc_transfer(0)
>   // test-internal stuff happening here, and then:
>   libusb_free_transfer(foo)
> without the transfer getting attached to any device along the way.
> As a result:
>   (gdb) print transfer
>   $1 = (struct libusb_transfer *) 0x1b2e3c8
>   (gdb) print transfer->dev_handle
>   $2 = (libusb_device_handle *) 0x0
> so TRANSFER_CTX (HANDLE_CTX, actually) is causing the null-dereference
> when accessing transfer->dev_handle->dev .
>
> If such call sequence is not supported, what would be the recommended
> way of writing tests around libusb ?
> I would rather not depend on any specific device being present to run
> tests - so far my only dependency is for any device to be present when
> testing device enumeration and hotplug callbacks, devices which are not
> opened by the test.
>

I believe the call sequence is not supported. As of now I believe it is not
possible to use libusb transfers without attaching to a USB device, which
means that it is not possible to carry out transfer related tests (no
matter the transfer type being control/interrupt/bulk/isochronous) without
using a specific device.

Maybe it is possible to have a "dummy" backend for libusb to enable such
functionality -- to test libusb without a physical USB device attached. The
dummy backend will need to support all transfer types. And I tend
to think this is not easy.

Similar discussions:
https://github.com/libusb/libusb/issues/1052
https://github.com/pyusb/pyusb/issues/235
https://github.com/LibUsbDotNet/LibUsbDotNet/issues/137

I actually think Linux dummy_hcd plus your python-functionfs is
a good combination. Windows WDK has software emulated
USB examples as well.

In the pyusb discussion, you can see pyftdi has created some
test suites without using real USB device, maybe you can try that
idea as well.

-- 
Xiaofan


_______________________________________________
libusb-devel mailing list
libusb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
[prev in list] [next in list] [prev in thread] [next in thread]