Bug 2050638

Summary:	libusb1 make some python3 programs crash
Product:	[Fedora] Fedora	Reporter:	edpil02 <edpil02>
Component:	libusb1	Assignee:	Benjamin Berg <bberg>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	36	CC:	bberg, hdegoede, jnovy, jv+fedora, lucilanga, rhbugs, victortoso
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-02-10 12:59:50 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description edpil02 2022-02-04 11:43:28 UTC

Get crashes with some python3 programs : libusb1-1.0.25-1-fc36.

1) (gdb) run /usr/bin/liquidctl list

Starting program: /usr/bin/python /usr/bin/liquidctl list
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after vfork from child process 17324]
[Detaching after vfork from child process 17325]
[New Thread 0x7ffff6e61640 (LWP 17326)]
[Thread 0x7ffff6e61640 (LWP 17326) exited]
libusb: debug [libusb_unref_device] destroy device 1.1

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x00007ffff6e679f4 in log_v () from /lib64/libusb-1.0.so.0
(gdb) bt
#0  0x00007ffff6e679f4 in log_v () from /lib64/libusb-1.0.so.0
#1  0x00007ffff6e67c2a in usbi_log () from /lib64/libusb-1.0.so.0
#2  0x00007ffff6e6caa0 in libusb_unref_device () from /lib64/libusb-1.0.so.0
#3  0x00007ffff73fe746 in ffi_call_unix64 () from /lib64/libffi.so.8
#4  0x00007ffff73fb4d2 in ffi_call_int.lto_priv () from /lib64/libffi.so.8
#5  0x00007ffff740bd4b in _ctypes_callproc.cold () from /usr/lib64/python3.10/lib-dynload/_ctypes.cpython-310-x86_64-linux-gnu.so
#6  0x00007ffff740b683 in PyCFuncPtr_call.cold () from /usr/lib64/python3.10/lib-dynload/_ctypes.cpython-310-x86_64-linux-gnu.so
#7  0x00007ffff7d6cf78 in _PyObject_MakeTpCall () from /lib64/libpython3.10.so.1.0


2)gdb) run ./playground.py

Starting program: /usr/bin/python ./playground.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after vfork from child process 25388]
[New Thread 0x7ffff710b640 (LWP 25389)]
[Thread 0x7ffff710b640 (LWP 25389) exited]
libusb: debug [libusb_unref_device] destroy device 1.1

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x00007ffff71119f4 in log_v () from /lib64/libusb-1.0.so.0
(gdb) bt
#0  0x00007ffff71119f4 in log_v () from /lib64/libusb-1.0.so.0
#1  0x00007ffff7111c2a in usbi_log () from /lib64/libusb-1.0.so.0
#2  0x00007ffff7116aa0 in libusb_unref_device () from /lib64/libusb-1.0.so.0
#3  0x00007ffff7256746 in ffi_call_unix64 () from /lib64/libffi.so.8
#4  0x00007ffff72534d2 in ffi_call_int.lto_priv () from /lib64/libffi.so.8
#5  0x00007ffff7263d4b in _ctypes_callproc.cold () from /usr/lib64/python3.10/lib-dynload/_ctypes.cpython-310-x86_64-linux-gnu.so
#6  0x00007ffff7263683 in PyCFuncPtr_call.cold () from /usr/lib64/python3.10/lib-dynload/_ctypes.cpython-310-x86_64-linux-gnu.so
#7  0x00007ffff7d6cf78 in _PyObject_MakeTpCall () from /lib64/libpython3.10.so.1.0
#8  0x00007ffff7d6a369 in _PyEval_EvalFrameDefault () from /lib64/libpython3.10.so.1.0

Comment 1 Benjamin Berg 2022-02-04 15:56:37 UTC

Is this a regression compared to libusb1-1.0.24?

Comment 2 Benjamin Berg 2022-02-04 19:25:05 UTC

OK, it is a regression, I'll cancel the updates for now. Will need to debug what is going on.

Comment 3 Benjamin Berg 2022-02-04 21:56:58 UTC

OK, opened https://github.com/libusb/libusb/pull/1058 upstream to fix this. I'll submit new packages later (hopefully upstream will ack them soon).

Comment 4 Benjamin Berg 2022-02-04 21:58:28 UTC

However, that said. I am thinking that the python USB wrapper might be a bit stupid. i.e. it should probably keep the USB context open while if one is still referencing a device.

Or libusb1 should be doing that, but I don't think it has refcounting for the USB context.

Comment 5 edpil02 2022-02-05 07:48:32 UTC

I don't know if there is a connection but all these programs use libusb to control usb RGB and ARGB devices : ( liquidctl , openrgb ..) and segfault randomly or all the time.
Thanks.

Comment 6 Ben Cotton 2022-02-08 20:14:55 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

Comment 7 Benjamin Berg 2022-02-10 12:59:50 UTC

New versions are on their way into F34, F35, F36 and F37 at this point.

F34: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9a7ecbb694
F35: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ca13cbc97f
F36: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6379467d61
F37: https://bodhi.fedoraproject.org/updates/FEDORA-2022-18b919e19c

Closing as fixed (sorry, forgot to mark the bug# in the updates).

Comment 8 Benjamin Berg 2022-02-10 13:00:46 UTC

For completeness sake. pyusb was also updated to fix the issue on their side. But, both updates individually will work fine. See https://bugzilla.redhat.com/show_bug.cgi?id=2051231