SUMMARY systemsettings kcm_gamecontroller shows that no controller is connected, hangs for 2 seconds, then segfaults. The controller is otherwise working eg in evtest and browser. STEPS TO REPRODUCE 1. systemsettings kcm_gamecontroller OBSERVED RESULT Crash EXPECTED RESULT Nice GUI that was there last time I tried (6.4.x?) SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20251031 KDE Plasma Version: 6.5.1 KDE Frameworks Version: 6.19.0 Qt Version: 6.10.0 Kernel Version: 6.17.6-1-default (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 32 GiB of RAM (31.2 GiB usable) Graphics Processor: NVIDIA GeForce RTX 3090 ADDITIONAL INFORMATION Thanks!
If something crashed, we need a backtrace of it so we can figure out what's going on. Can you please attach a backtrace of the crash using the coredumpctl command-line program, as detailed in https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl? Thanks!
Sorry, I thought maybe it was reproducible at your end. I guess I broke it XD (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=11, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007f4f1369de33 in __pthread_kill_internal (threadid=<optimized out>, signo=11) at pthread_kill.c:89 #2 0x00007f4f136427b6 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26 #3 0x00007f4f17005390 in KCrash::defaultCrashHandler(int) () at /lib64/libKF6Crash.so.6 #4 0x00007f4f13642910 in <signal handler called> () at /lib64/libc.so.6 #5 __wcslen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76 #6 0x00007f4ed3cf89fc in ??? () at /lib64/libSDL3.so.0 #7 0x00007f4eee5c7d7f in ??? () at /lib64/libSDL2-2.0.so.0 #8 0x00007f4efffa8e16 in ??? () at /usr/lib64/qt6/plugins/plasma/kcms/systemsettings/kcm_gamecontroller.so #9 0x00007f4efffaab2f in ??? () at /usr/lib64/qt6/plugins/plasma/kcms/systemsettings/kcm_gamecontroller.so #10 0x00007f4f14035c20 in QtPrivate::QSlotObjectBase::call (this=0x564c39b03ae0, r=<optimized out>, a=0x7ffcafc8c2b8) at /usr/src/debug/qtbase-everywhere-src-6.10.0/src/corelib/kernel/qobjectdefs_impl.h:461 #11 doActivate<false> (sender=0x564c39147750, signal_index=3, argv=0x7ffcafc8c2b8) at /usr/src/debug/qtbase-everywhere-src-6.10.0/src/corelib/kernel/qobject.cpp:4255 #12 0x00007f4f1403c57c in QSingleShotTimer::timeout (this=0x564c39147750) at /usr/src/debug/qtbase-everywhere-src-6.10.0/build/src/corelib/Core_autogen/include/moc_qsingleshottimer_p.cpp:116 #13 QSingleShotTimer::timerFinished (this=0x564c39147750) at /usr/src/debug/qtbase-everywhere-src-6.10.0/src/corelib/kernel/qsingleshottimer.cpp:62 #14 QSingleShotTimer::timerEvent (this=0x564c39147750, event=<optimized out>) at /usr/src/debug/qtbase-everywhere-src-6.10.0/src/corelib/kernel/qsingleshottimer.cpp:84 #15 0x00007f4f14023626 in QObject::event (this=<optimized out>, e=<optimized out>) at /usr/src/debug/qtbase-everywhere-src-6.10.0/src/corelib/kernel/qobject.cpp:1386 #16 0x00007f4f151e7918 in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x564c39147750, e=0x7ffcafc8c490) at /usr/src/debug/qtbase-everywhere-src-6.10.0/src/widgets/kernel/qapplication.cpp:3307 #17 0x00007f4f13fcdc98 in QCoreApplication::notifyInternal2 (receiver=0x564c39147750, event=0x7ffcafc8c490) at /usr/src/debug/qtbase-everywhere-src-6.10.0/src/corelib/kernel/qcoreapplication.cpp:1109 #18 0x00007f4f141729bc in QTimerInfoList::activateTimers (this=0x564c38366d80) at /usr/src/debug/qtbase-everywhere-src-6.10.0/src/corelib/kernel/qtimerinfo_unix.cpp:426 #19 0x00007f4f14295f1c in timerSourceDispatch (source=source@entry=0x564c38366d20) at /usr/src/debug/qtbase-everywhere-src-6.10.0/src/corelib/kernel/qeventdispatcher_glib.cpp:152 #20 0x00007f4f130eab36 in g_main_dispatch (context=0x7f4f08000f60) at ../glib/gmain.c:3565 #21 g_main_context_dispatch_unlocked (context=context@entry=0x7f4f08000f60) at ../glib/gmain.c:4425 #22 0x00007f4f130eda28 in g_main_context_iterate_unlocked (context=context@entry=0x7f4f08000f60, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4490 #23 0x00007f4f130ee26c in g_main_context_iteration (context=0x7f4f08000f60, may_block=1) at ../glib/gmain.c:4556 #24 0x00007f4f14294038 in QEventDispatcherGlib::processEvents (this=0x564c383143d0, flags=...) at /usr/src/debug/qtbase-everywhere-src-6.10.0/src/corelib/kernel/qeventdispatcher_glib.cpp:399 #25 0x00007f4f13fdc12b in QEventLoop::exec (this=0x7ffcafc8c700, flags=...) at /usr/src/debug/qtbase-everywhere-src-6.10.0/src/corelib/global/qflags.h:77 #26 0x00007f4f13fd2bd3 in QCoreApplication::exec () at /usr/src/debug/qtbase-everywhere-src-6.10.0/src/corelib/kernel/qcoreapplication.cpp:1452 #27 0x0000564bf9785456 in ??? () #28 0x00007f4f1362b2fb in __libc_start_call_main (main=main@entry=0x564bf9784310, argc=argc@entry=2, argv=argv@entry=0x7ffcafc8cbf8) at ../sysdeps/nptl/libc_start_call_main.h:58 #29 0x00007f4f1362b3cb in __libc_start_main_impl (main=0x564bf9784310, argc=2, argv=0x7ffcafc8cbf8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcafc8cbe8) at ../csu/libc-start.c:360 #30 0x0000564bf9786095 in ??? () (gdb)
Thanks. I am unable to reproduce this on my end. Does this happen only when your game controller is connected? If so, which controller are you using?
(In reply to duha.bugs from comment #3) > Does this happen only when your game controller is connected? If so, which > controller are you using? Thanks for your help! It happens even when the controller is not connected. It's an xbox one controller.
i can reproduce this on git-master with no controller connected (none are configured) kcmshell6 kcm_gamecontroller [1] 430914 segmentation fault (core dumped) kcmshell6 kcm_gamecontroller The backtrace looks a little different for me, probably because my system has Qt 6.9.3
*** Bug 511859 has been marked as a duplicate of this bug. ***
Created attachment 187080 [details] gdb log (segfault is on thread 1) I have been experiencing a similar crash. I'm on CachyOS which is an Arch Linux derivative. Here's the gdb log. I can go deeper down the debug rabbit hole if required.
Created attachment 187081 [details] "lsusb -v" for the USB device causing the crash After glancing at the stack trace, and looking at the bug report marked duplicate, at least my crash appears to be because of this specific device, which reports a game controller, but also is probably breaking expectations in other ways. This is an extremely cheap foot pedal from Amazon so I wouldn't be surprised if this thing is misbehaving.
(In reply to Jacob Godserv from comment #8) > Created attachment 187081 [details] > "lsusb -v" for the USB device causing the crash > > After glancing at the stack trace, and looking at the bug report marked > duplicate, at least my crash appears to be because of this specific device, > which reports a game controller, but also is probably breaking expectations > in other ways. This is an extremely cheap foot pedal from Amazon so I > wouldn't be surprised if this thing is misbehaving. I should've added that the crash goes away if this device is unplugged.
(In reply to Jacob Godserv from comment #8) > Created attachment 187081 [details] > "lsusb -v" for the USB device causing the crash > > After glancing at the stack trace, and looking at the bug report marked > duplicate, at least my crash appears to be because of this specific device, > which reports a game controller, but also is probably breaking expectations > in other ways. This is an extremely cheap foot pedal from Amazon so I > wouldn't be surprised if this thing is misbehaving. Nice one! I have the same 1a86:e026 device. They're VERY popular. I hope you'd be so kind as to tell me where in the stack trace you saw this device mentioned? I was entertaining the possibility that one of my mice which exposes a game controller, was the problem here. I never thought of that footswitch. lsusb just says it's a HID device so didn't really tell me it was a controller. I'd like to be able to be more helpful next time I see a problem like this.
(In reply to pallaswept from comment #10) > (In reply to Jacob Godserv from comment #8) > > Created attachment 187081 [details] > > "lsusb -v" for the USB device causing the crash > > > > After glancing at the stack trace, and looking at the bug report marked > > duplicate, at least my crash appears to be because of this specific device, > > which reports a game controller, but also is probably breaking expectations > > in other ways. This is an extremely cheap foot pedal from Amazon so I > > wouldn't be surprised if this thing is misbehaving. > > Nice one! I have the same 1a86:e026 device. They're VERY popular. > > I hope you'd be so kind as to tell me where in the stack trace you saw this > device mentioned? I was entertaining the possibility that one of my mice > which exposes a game controller, was the problem here. I never thought of > that footswitch. lsusb just says it's a HID device so didn't really tell me > it was a controller. I'd like to be able to be more helpful next time I see > a problem like this. I checked the stacktrace and saw it was checking a string and getting an access error on a pointer. I then saw in the duplicate bug someone made mention to the manufacturer field being empty in their debugging session. I immediately got suspicious of that cheap foot pedal and unplugged it. I knew it exposes a gamepad because it shows up in my Steam Proton games as a device I can pick.
A portion of the stack trace for this bug report (which I've included below) suggests that the final issue is similar to one I reported in my Bug 511859. My bug report clearly states that the problem is due to passing a variable containing 0 to SDL instead of a pointer to a string. In my bug report, the problem is: (gdb) p i->manufacturer_string $4 = 0x0 ------------------------------------------------- #5 __wcslen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76 #6 0x00007f4ed3cf89fc in ??? () at /lib64/libSDL3.so.0
Another crash report came in for this, with a more complete backtrace. I'm going to merge this report into that one. *** This bug has been marked as a duplicate of bug 513074 ***