SUMMARY Activating link to bash scripts causes system to freeze until restarted (REISUB); Links to bash scripts created before upgrade to 6.1.5 (from 6.0) still work; STEPS TO REPRODUCE 1. Create link to bash script; 2. Activate link (mouse click); 3. System freeze. OBSERVED RESULT System freeze. EXPECTED RESULT Bash script runs; no freezing; SOFTWARE/OS VERSIONS Linux/KDE Plasma: ManjaroLinux; 24.1.1; Xahea; KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION 6 × Intel® Core™ i5-8600K CPU @ 3.60GHz; 31.3 GiB of RAM; NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2;
I am not able to reproduce this in git-master with a simple hello world bash script. I also can't reproduce on Plasma 6.2.3 with a simple script that prints the contents of /etc/os-release I need more detail to try to determine what's happening. 1. Is this happening with all shortcuts to all your bash scripts, or specific scripts? 2. When you say "activate link", are you saying you're Executing the script? 3. What happens if you Right click the link and choose - actions - Run in Konsole? Thanks
(In reply to TraceyC from comment #1) > I am not able to reproduce this in git-master with a simple hello world bash > script. > I also can't reproduce on Plasma 6.2.3 with a simple script that prints the > contents of /etc/os-release > > I need more detail to try to determine what's happening. > 1. Is this happening with all shortcuts to all your bash scripts, or > specific scripts? > > 2. When you say "activate link", are you saying you're Executing the script? > > 3. What happens if you Right click the link and choose - actions - Run in > Konsole? > > Thanks Yes, it happens with all my bash shell scripts (which are in sub-sub-directories in my home directory), which are set to open on left click with Kate. If I left click on the .sh file, however, my system freezes completely, and doesn't recover. I then reboot with REISUB. If I create a 'link to application' to the .sh file (placed on my desktop), my system freezes also, on left click. When I right click on the file (any .sh file), I can select 'Open with Kate' without any issues. All my scripts run without any issues if I select 'Run in Konsole', as expected. Yes, when I say "activate link" I mean execute the script (sorry, clumsy language there). I've just tried something -- I managed to create a 'link to application' to a .sh file in my home directory (not a sub-directory thereof) which works perfectly; the other issues remain unchanged. I also just tried left clicking on a .sh file in a sub-directory in my home directory -- nothing happens; there's also no freeze; similarly, if I create a 'link to application' to a shell file in a sub-directory in my home directory, nothing happens, and there's no freeze, In short: Left clicking on a .sh file in a sub-sub-directory of my home directory (which should cause it to open with Kate) makes my system freeze; Left clicking on a 'link to application' to a .sh file in a sub-sub-directory of my home directory causes my system to freeze; Left clicking on a .sh file in a sub-directory of my home directory (which should cause it to open with Kate) produces no result, but my system doesn't freeze; Left clicking on a 'link to application' to a .sh file in a sub-directory of my home directory produces no result, but my system doesn't freeze; Left clicking on a .sh file (which has a working 'link to application' on my desktop) in my home directory (which should cause it to open with Kate), causes dolphin to crash; (which I just tried while typing this) Left clicking on a 'link to application' to a .sh file in my home directory works as expected -- the script runs.
Thanks for those details, that will help. We also need to know why KWin crashed / froze. For that, we need a backtrace of the crash for the kwin_wayland process. You may be able to retrieve it with coredumpctl. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl If you can get a backtrace, please attach or copy it into this bug report. Thanks!
(In reply to TraceyC from comment #3) > Thanks for those details, that will help. We also need to know why KWin > crashed / froze. For that, we need a backtrace of the crash for the > kwin_wayland process. You may be able to retrieve it with coredumpctl. See > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl > > If you can get a backtrace, please attach or copy it into this bug report. > Thanks! Here's the whole output of <coredumpctl -- reverse> (made immediately after another crash, and reboot): TIME PID UID GID SIG COREFILE EXE SIZE Tue 2024-11-19 11:04:43 SAST 2031 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 11:04:43 SAST 2014 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 11:04:42 SAST 1997 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 11:04:42 SAST 1980 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 11:04:42 SAST 1962 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 11:04:41 SAST 544 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 11:03:43 SAST 1074 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 11:03:29 SAST 993 960 960 SIGSEGV inaccessible /usr/bin/sddm-greeter-qt6 - Tue 2024-11-19 10:52:59 SAST 2022 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 10:52:59 SAST 2005 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 10:52:58 SAST 1988 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 10:52:58 SAST 1971 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 10:52:58 SAST 1953 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 10:52:57 SAST 539 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 10:01:32 SAST 1937 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 10:01:31 SAST 1920 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 10:01:31 SAST 1900 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 10:01:31 SAST 1886 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 10:01:31 SAST 1869 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Tue 2024-11-19 10:01:30 SAST 550 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Mon 2024-11-18 17:17:23 SAST 12161 1000 1000 SIGSEGV present /opt/zoom/ZoomWebviewHost 8.3M Mon 2024-11-18 17:17:23 SAST 12160 1000 1000 SIGSEGV present /opt/zoom/ZoomWebviewHost 8.4M Mon 2024-11-18 17:17:23 SAST 12159 1000 1000 SIGSEGV present /opt/zoom/ZoomWebviewHost 8.8M Mon 2024-11-18 17:17:23 SAST 12158 1000 1000 SIGSEGV present /opt/zoom/ZoomWebviewHost 8.1M Mon 2024-11-18 17:17:23 SAST 12157 1000 1000 SIGSEGV present /opt/zoom/ZoomWebviewHost 8.3M Mon 2024-11-18 16:44:19 SAST 1221 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Mon 2024-11-18 16:44:19 SAST 1204 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Mon 2024-11-18 16:44:18 SAST 1187 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Mon 2024-11-18 16:44:18 SAST 1170 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Mon 2024-11-18 16:44:18 SAST 1153 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Mon 2024-11-18 16:44:17 SAST 540 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Mon 2024-11-18 09:48:18 SAST 2258 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Mon 2024-11-18 09:48:18 SAST 2238 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Mon 2024-11-18 09:48:18 SAST 2224 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Mon 2024-11-18 09:48:17 SAST 2207 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Mon 2024-11-18 09:48:17 SAST 2190 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd - Mon 2024-11-18 09:48:17 SAST 545 975 975 SIGSEGV inaccessible /usr/lib/systemd/systemd-timesyncd -
The list of the coredumps on your system doesn't give us the information we need. What we need is a backtrace of *one* coredump - the one that corresponds to the last time the system froze. Please read through this to find out how to do that: https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl
(In reply to TraceyC from comment #5) > The list of the coredumps on your system doesn't give us the information we > need. What we need is a backtrace of *one* coredump - the one that > corresponds to the last time the system froze. Please read through this to > find out how to do that: > > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl I'm at a loss.. Subsequent coredumps (<coredumpctl --reverse>, and <sudo coredumpctl --reverse>) -- made immediately upon reboot after a crash -- are no different. <valgrind --log-file=konsole konsole> produces the following (generating the file "konsole"): ==5402== Memcheck, a memory error detector ==5402== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==5402== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info ==5402== Command: konsole ==5402== Parent PID: 4945 ==5402== <coredumpctl gdb 4945> produces: No match found. <valgrind --log-file=kwin kwin> (I tried kwin; Kwin; KWin) produces: valgrind: kwin: command not found
Thinking about what you had described so far, you had said these scripts are in a subdirectory some levels below your home directory. Are all of the directories in between readable by your user? (As in, no root owned directories above the directory where the scripts are)? In regards to getting a good backtrace - if you have a Wayland session you won't have a process named "kwin", it will be "kwin_wayland". You can see the name of the kwin process in your current login session with pgrep -fla kwin if that doesn't work, try ps -ef |grep kwin) and then the number after your username is the pid Once you have that pid, use it to retrieve a backtrace with GDB https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_GDB At this point I think gdb will be more useful than coredumpctl
(In reply to TraceyC from comment #7) > Thinking about what you had described so far, you had said these scripts are > in a subdirectory some levels below your home directory. Are all of the > directories in between readable by your user? (As in, no root owned > directories above the directory where the scripts are)? > > In regards to getting a good backtrace - if you have a Wayland session you > won't have a process named "kwin", it will be "kwin_wayland". You can see > the name of the kwin process in your current login session with > > pgrep -fla kwin > > if that doesn't work, try > ps -ef |grep kwin) > > and then the number after your username is the pid > Once you have that pid, use it to retrieve a backtrace with GDB > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_GDB > > At this point I think gdb will be more useful than coredumpctl Okay, my apologies for the long delay; I am officially an ID10T I have subsequently reinstalled my system -- plasma 6.5.1(In reply to TraceyC from comment #7) > Thinking about what you had described so far, you had said these scripts are > in a subdirectory some levels below your home directory. Are all of the > directories in between readable by your user? (As in, no root owned > directories above the directory where the scripts are)? > > In regards to getting a good backtrace - if you have a Wayland session you > won't have a process named "kwin", it will be "kwin_wayland". You can see > the name of the kwin process in your current login session with > > pgrep -fla kwin > > if that doesn't work, try > ps -ef |grep kwin) > > and then the number after your username is the pid > Once you have that pid, use it to retrieve a backtrace with GDB > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_GDB > > At this point I think gdb will be more useful than coredumpctl Okay, I am officially an ID10T -- my apologies for the long delay, and for wasting your time. In the interim, I reinstalled my system (Plasma 6.1.5 on Manjaro) and, this morning, updated to Plasma 6.2.4 (on X11). I then caused my system to crash again, as before, before looking closer at my 'Link to Application-, only to discover that I never specified that the script should run in the terminal (Konsole). Upon specifying that the script should run in the terminal, it worked as expected. Maybe it still qualifies as a bug since, if there's no direction that the script should run in the terminal, my system crashes. Many thanks, and kind regards. Mark
(In reply to Mark from comment #8) > (In reply to TraceyC from comment #7) > > Thinking about what you had described so far, you had said these scripts are > > in a subdirectory some levels below your home directory. Are all of the > > directories in between readable by your user? (As in, no root owned > > directories above the directory where the scripts are)? > > > > In regards to getting a good backtrace - if you have a Wayland session you > > won't have a process named "kwin", it will be "kwin_wayland". You can see > > the name of the kwin process in your current login session with > > > > pgrep -fla kwin > > > > if that doesn't work, try > > ps -ef |grep kwin) > > > > and then the number after your username is the pid > > Once you have that pid, use it to retrieve a backtrace with GDB > > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > > How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_GDB > > > > At this point I think gdb will be more useful than coredumpctl > > Okay, my apologies for the long delay; I am officially an ID10T > > I have subsequently reinstalled my system -- plasma 6.5.1(In reply to > TraceyC from comment #7) > > Thinking about what you had described so far, you had said these scripts are > > in a subdirectory some levels below your home directory. Are all of the > > directories in between readable by your user? (As in, no root owned > > directories above the directory where the scripts are)? > > > > In regards to getting a good backtrace - if you have a Wayland session you > > won't have a process named "kwin", it will be "kwin_wayland". You can see > > the name of the kwin process in your current login session with > > > > pgrep -fla kwin > > > > if that doesn't work, try > > ps -ef |grep kwin) > > > > and then the number after your username is the pid > > Once you have that pid, use it to retrieve a backtrace with GDB > > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > > How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_GDB > > > > At this point I think gdb will be more useful than coredumpctl > > Okay, I am officially an ID10T -- my apologies for the long delay, and for > wasting your time. > > In the interim, I reinstalled my system (Plasma 6.1.5 on Manjaro) and, this > morning, updated to Plasma 6.2.4 (on X11). > > I then caused my system to crash again, as before, before looking closer at > my 'Link to Application-, only to discover that I never specified that the > script should run in the terminal (Konsole). > > Upon specifying that the script should run in the terminal, it worked as > expected. > > Maybe it still qualifies as a bug since, if there's no direction that the > script should run in the terminal, my system crashes. > > Many thanks, and kind regards. > > Mark I just ran: echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope gdb -pid $(pidof kwin_x11) -batch -ex "set logging file kwin_x11.gdb" -ex "set logging enabled on" -ex "continue" -ex "thread apply all backtrace" -ex "quit" I then tried left clicking on a .sh file to open it, and selected 'execute', upon which my system froze again. I did this twice, and was rewarded with two files in my home directory, the content of which is the following: [Thread 0x7494d6ffe6c0 (LWP 2460) exited] [Thread 0x7494d67fd6c0 (LWP 2459) exited] [New Thread 0x7494d6ffe6c0 (LWP 2559)] [New Thread 0x7494d67fd6c0 (LWP 2560)] [Inferior 1 (process 1206) detached] [Thread 0x7494d67fd6c0 (LWP 2560) exited] [Thread 0x7494d6ffe6c0 (LWP 2559) exited] [New Thread 0x7494d67fd6c0 (LWP 2684)] [New Thread 0x7494d6ffe6c0 (LWP 2685)] [Thread 0x7494f766d6c0 (LWP 1313) exited] [Thread 0x74950e2ecf80 (LWP 1206) exited] [Thread 0x7494e2d796c0 (LWP 1330) exited] [Thread 0x74950bd5b6c0 (LWP 1231) exited] and [Inferior 1 (process 1212) detached] I ran ps -ef |grep kwin, and (gdb) kwin 11092, but kwin, Kwin, KWin, and KWIN were rejected as being 'undefined'.. I hope this helps.. Regards Mark
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.