You are not logged in.
I just did a system update yesterday after having not for about a month, and after doing so, cameractrlsgtk4 is behaving oddly.
Upon opening the application, python segfaults, but the application keeps working.
Each interaction, button, tab change, toggle, python segfaults again.
However, the application works, and the functions I use it for all seem to work as well.
If it weren't for the fact that KDE shows a toast notification when a segfault occurs, I would not have even realized it was happening.
An example of one of the times it segfaulted from the journal is
Mar 17 21:26:30 ragnarok systemd[1563]: Started Cameractrls.
Mar 17 21:26:30 ragnarok kernel: python3[341900]: segfault at 0 ip 00007f17e0203bac sp 00007ffd23eee1c0 error 4 in libpython3.14.so.1.0[203bac,7f17e003d000+2fe000] likely on CPU 14 (core 28, socket 0)
Mar 17 21:26:30 ragnarok kernel: Code: 8a e6 f5 ff eb 24 66 90 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 4d 39 e6 0f 84 b8 01 00 00 4c 89 e3 <48> 8b 03 48 89 c2 48 83 e2 fc 49 89 d4 4c 39 6b 18 75 e1 48 85 c0
Mar 17 21:26:30 ragnarok systemd-coredump[341902]: Process 341900 (python3) of user 1000 terminated abnormally with signal 11/SEGV, processing...
Mar 17 21:26:30 ragnarok systemd[1]: Started Process Core Dump (PID 341902/UID 0).
Mar 17 21:26:30 ragnarok systemd[1]: Started Pass systemd-coredump journal entries to relevant user for potential DrKonqi handling.
Mar 17 21:26:30 ragnarok systemd-coredump[341903]: [?] Process 341900 (python3) of user 1000 dumped core.
Stack trace of thread 341900:
#0 0x00007f17e0203bac n/a (libpython3.14.so.1.0 + 0x203bac)
#1 0x00007f17e026be74 n/a (libpython3.14.so.1.0 + 0x26be74)
#2 0x00007f17e028ff64 n/a (libpython3.14.so.1.0 + 0x28ff64)
#3 0x00007f17e02bb10f Py_Exit (libpython3.14.so.1.0 + 0x2bb10f)
#4 0x00007f17e02b88c9 n/a (libpython3.14.so.1.0 + 0x2b88c9)
#5 0x00007f17e02b8603 n/a (libpython3.14.so.1.0 + 0x2b8603)
#6 0x00007f17e0095528 n/a (libpython3.14.so.1.0 + 0x95528)
#7 0x00007f17e02ab817 n/a (libpython3.14.so.1.0 + 0x2ab817)
#8 0x00007f17e025e508 Py_RunMain (libpython3.14.so.1.0 + 0x25e508)
#9 0x00007f17e0257c6b Py_BytesMain (libpython3.14.so.1.0 + 0x257c6b)
#10 0x00007f17dfe366c1 n/a (libc.so.6 + 0x276c1)
#11 0x00007f17dfe367f9 __libc_start_main (libc.so.6 + 0x277f9)
#12 0x00005647887a8045 _start (/usr/bin/python3.14 + 0x1045)
ELF object binary architecture: AMD x86-64
Mar 17 21:26:30 ragnarok systemd[1]: systemd-coredump@3-20483-341902_341903-0.service: Deactivated successfully.The KDE dialog for this provided the command line that was in use when this occurred which is
python3 /usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py -lThe help for that script outputs
usage: /usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py [-h] [-l] [-c] [-d DEVICE]
optional arguments:
-h, --help show this help message and exit
-l, --list list midi controllers
-c, --controller use controller (client:port), default first
-d DEVICE use DEVICE, default /dev/video0
example:
/usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py -d /dev/video4And when I try manually to run that with the -l switch I get a segfault
python3 /usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py -l
ERROR:root:Couldn't find hw devices
Segmentation fault (core dumped) python3 /usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py -lI did a pacman -Qo on everything in /usr/lib/python3.14/site-packages and it all checked out
Using that to get the package names, I checked with paccheck, and found no issues.
I'm at a loss as to what's happening or how to fix it on this one.
Last edited by Ketrel (2026-03-22 05:22:20)
Offline
Please provide a bactrace with debug symbols.
Edit:
Can you also try:
python -X dev /usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py -lThis enables additional expensive runtime checking.
If in /usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py you replace:
ports = get_hw_client_ports(seq)
if not ports:
logging.error("Couldn't find hw devices")
sys.exit(2)with
ports = get_hw_client_ports(seq)
if not ports:
logging.error("Couldn't find hw devices")
os._exit(2)Does that avoid the issue?
Last edited by loqs (2026-03-19 00:04:51)
Offline
I hope I did this right
Hopefully what you wanted from the gdb output: https://paste.rs/1OS1y
Output of python -X
$ python -X dev /usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py -l
/usr/lib/python3.14/site-packages/CameraCtrls/cameractrls.py:297: DeprecationWarning: Due to '_pack_', the 'v4l2_plane_pix_format' Structure will use memory layout compatible with MSVC (Windows). If this is intended, set _layout_ to 'ms'. The implicit default is deprecated and slated to become an error in Python 3.19.
class v4l2_plane_pix_format(ctypes.Structure):
/usr/lib/python3.14/site-packages/CameraCtrls/cameractrls.py:306: DeprecationWarning: Due to '_pack_', the 'v4l2_pix_format_mplane' Structure will use memory layout compatible with MSVC (Windows). If this is intended, set _layout_ to 'ms'. The implicit default is deprecated and slated to become an error in Python 3.19.
class v4l2_pix_format_mplane(ctypes.Structure):
/usr/lib/python3.14/site-packages/CameraCtrls/cameractrls.py:821: DeprecationWarning: Due to '_pack_', the 'v4l2_querymenu' Structure will use memory layout compatible with MSVC (Windows). If this is intended, set _layout_ to 'ms'. The implicit default is deprecated and slated to become an error in Python 3.19.
class v4l2_querymenu(ctypes.Structure):
Debug memory block at address p=0x7f438a999d80: API 'm'
156 bytes originally requested
The 7 pad bytes at p-7 are FORBIDDENBYTE, as expected.
The 8 pad bytes at tail=0x7f438a999e1c are not all FORBIDDENBYTE (0xfd):
at tail+0: 0x00 *** OUCH
at tail+1: 0x00 *** OUCH
at tail+2: 0x00 *** OUCH
at tail+3: 0x00 *** OUCH
at tail+4: 0x00 *** OUCH
at tail+5: 0x00 *** OUCH
at tail+6: 0x00 *** OUCH
at tail+7: 0x00 *** OUCH
Data at p: 8f 00 00 00 01 00 00 00 ... 00 00 00 00 00 00 00 00
Enable tracemalloc to get the memory block allocation traceback
Fatal Python error: _PyMem_DebugRawFree: bad trailing pad byte
Python runtime state: initialized
Current thread 0x00007f438c864b80 [python] (most recent call first):
File "/usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py", line 382 in main
File "/usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py", line 442 in <module>
Aborted (core dumped) python -X dev /usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py -lAs for changing sys.exit(2) to os._exit(2) yes, that appears to exit cleanly without a segfault.
Offline
If you reinstall cameractls to undo the last change then change /usr/lib/python3.14/site-packages/CameraCtrls/cameractrls.py
('raw_data', ctypes.c_char * 200),to
('raw_data', ctypes.c_char * 256),Does that help? This is just a guess that not enough memory was allocated based on the python -X output. I suggest reporting it upstream so they can provide a proper fix.
Offline
Unfortunately no, that changes does not help. It still segfaults with that change.
(And that line is in cameractrls.py twice, it made no difference if I changed either or both)
Offline
I suspect there is either a latent bug in cameractls that was uncovered by python 3.14s changes to memory handling or a bug in python most likely in ctypes. Which is why I suggested reporting the issue upstream.
Offline
Right now though it seems like it's only me, unless you were able to replicate it?
Offline
I was able to reproduce:
$ python /usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py -l
ERROR:root:Couldn't find hw devices
Segmentation fault (core dumped) python /usr/lib/python3.14/site-packages/CameraCtrls/cameraptzmidi.py -lLast edited by loqs (2026-03-19 23:53:05)
Offline
https://github.com/soyersoyer/cameractrls/issues/99
We'll see what happens I guess. In the mean time is there any reason I should not use os._exit() ?
Offline
In the mean time is there any reason I should not use os._exit() ?
No reason not to as temporary work around.
Offline
Looks like it was a code bug in cameractrls which became evident in python 3.14 as you suspected. They found and fixed it.
(Also pretty easy from the git diff to do locally until the package gets the fix)
Thanks, I'll edit it as solved.
Offline