Version: 4.7 (using KDE 4.7.3) OS: Linux touch ~/.kde4/Autostart/file.log $ ll ~/.kde4/Autostart/file.log -rw-r--r-- 1 divan users 0 Nov 15 10:41 /home/divan/.kde4/Autostart/file.log $ file ~/.kde4/Autostart/file.log /home/divan/.kde4/Autostart/file.log: empty then reboot and login in to kde. one will notice that if you then try to launch some applications like firefox/rekonq/kwrite they all just hang from command line and don't open. The reason is the kwrite has spawned in the background upon logging in and is trying to open "/home/divan/.kde4/Autostart/file.log" but is hanging. Killing this process makes the system resume to normal. This is rather severe since it basically makes KDE completely unusable if one puts a text file(that kwrite spawns) in the Autostart directory. Most users won't know what is going on and there kde will be broken. To fix simply remove the file. I came across this bug since latest davmail creates an empty davmail.log file in the Autostart directory and thereafter my system was broken because of this bug. If the file is not empty this bug still occures. Reproducibility: always. Reproducible: Always Steps to Reproduce: As per above Actual Results: As per above Expected Results: If a plain text file(not executable) is in Autostart directory, kwrite should launch it with no problem, not hang, and not hang other processes. kde 4.7.3
I can reproduce the reported problem using KDE SC 4.8 beta2.
I can reproduce this using KDE 4.9.1.
I've also just experienced this problem with KDE 4.9.2. I was temporarily disabling a script under autostart by removing its executable attribute, little did I know it made the whole desktop totally unusable as programs couldn't be opened and most programs restored by the session manager tend to hang a lot.
see https://git.reviewboard.kde.org/r/106911/
What I don't understand, is why new KRun("emptyfile.log") would hang the whole system. Sounds like a bug in klauncher? Seems to me that what should be fixed is rather that bug. If you had seen a kwrite showing the text file, you would have simply concluded that KDE "opens" any file in the autostart folder, including text files, and that would be a feature rather than a bug (I can think of use cases for that, such as automatically opening up your todo list in an app that doesn't support session management). OK, corner case feature, we can live without it of course.
well, actually kwrite is not even successfully started to open that empty file Here is the backtrace of the stuck process "kdeinit4: kwrite [kdeinit] /home/dummy/.kde4/Autostart/file.log" #0 0xb7734424 in __kernel_vsyscall () #1 0xb6b9cc33 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:82 #2 0xb5e3999f in ?? () from /usr/lib/libICE.so.6 Backtrace stopped: previous frame inner to this frame (corrupt stack?) And here is the backtrace of process "kdeinit4: kdeinit4 Running..." #0 0xb7734424 in __kernel_vsyscall () #1 0xb5f3a63d in ___newselect_nocancel () at ../sysdeps/unix/syscall-template.S:82 #2 0x08051172 in handle_requests (waitForPid=<optimized out>) at /mnt/personal/build/portage/kde-base/kdelibs-9999/work/kdelibs-9999/kinit/kinit.cpp:1385 #3 0x0804c95a in main (argc=456, argv=0x0, envp=0x0) at /mnt/personal/build/portage/kde-base/kdelibs-9999/work/kdelibs-9999/kinit/kinit.cpp:1899
Forgetting to add "#!/bin/bash" in the script file also trigger this problem.
A better backtrace of the stuck kwrite: #0 0xb773c424 in __kernel_vsyscall () #1 0xb6ba4c33 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:82 #2 0xb5e3e552 in read (__nbytes=8, __buf=0xa0998d8, __fd=<optimized out>) at /usr/include/bits/unistd.h:45 #3 _IceTransSocketRead (ciptr=0xa078378, buf=0xa0998d8 "\260\326\377\265XZ\t\n", size=8) at /usr/include/X11/Xtrans/Xtranssock.c:2116 #4 0xb5e404ef in _IceTransRead (ciptr=0xa078378, buf=0xa0998d8 "\260\326\377\265XZ\t\n", size=8) at /usr/include/X11/Xtrans/Xtrans.c:863 #5 0xb5e42dd9 in _IceRead (iceConn=0xa076268, nbytes=8, ptr=0xa0998d8 "\260\326\377\265XZ\t\n") at /tmp/portage/x11-libs/libICE-1.0.8/work/libICE-1.0.8/src/misc.c:228 #6 0xb5e46ff8 in IceProcessMessages (iceConn=0xa076268, replyWait=0x0, replyReadyRet=0x0) at /tmp/portage/x11-libs/libICE-1.0.8/work/libICE-1.0.8/src/process.c:196 #7 0xb5e3c06d in IceOpenConnection ( networkIdsList=0x9fc6848 "local/gentoo:@/tmp/.ICE-unix/11436,unix/gentoo:/tmp/.ICE-unix/11436", context=0x0, mustAuthenticate=0, majorOpcodeCheck=1, errorLength=256, errorStringRet=0xbf8fcd24 "") at /tmp/portage/x11-libs/libICE-1.0.8/work/libICE-1.0.8/src/connect.c:258 #8 0xb5e53aa3 in SmcOpenConnection () from /usr/lib/libSM.so.6 #9 0x00000100 in ?? () #10 0xbf8fcd24 in ?? ()
*** Bug 313445 has been marked as a duplicate of this bug. ***
I would also like to chime in and confirm this bug still exists in KDE 4.10.5. Like Simon Yuan above, I just wanted to temporarily disable a script in the Autorun directory and it just took me several hours of searching both the Internet and the system for any traces of error messages -- there were none of course. It took me a while to realize I could launch KDE applications through a tty by prepending "DISPLAY=:0" to the command line as I was unable to launch both Konsole and Yakuake through the Plasma/KRunner interface. Eventually I noticed the starting session of KDE attempts to launch Kate. Eventually after manually launching Kate from the Konsole, it displayed the disabled script's content. If you ask me, this issue is way more severe than "normal". The system should simply ignore any script in Autorun that does not have executable flag set.
*** Bug 322685 has been marked as a duplicate of this bug. ***
*** Bug 325434 has been marked as a duplicate of this bug. ***
Agree with Zbynek, this is a severe bug since it renders the whole desktop unusable and is not obvious to track down (I wasted 90 min until I found https://bbs.archlinux.org/viewtopic.php?pid=1354037). Jekyll, was your patch ever integrated? I hit this problem in KDE 4.11.4. Thanks for creating it BTW.
It took me more than two hours to debug why my session was broken, and in the end this bug was the cause. This is with KDE 4.13.0. You can get yourself in this broken state entirely via the GUI, no need for an application to put a log file there: 1. Go to System Settings → Start and Stop¹ → Autostart 2. Click on the Add script button. 3. Choose any text file. Voilà, your desktop will be severely incapacitated starting from the next login. In my case, the text file was a shell script I just created but forgot to make executable. An easy mistake to make, IMHO. Since I did a lot of debugging, I'll attach the backtrace of ksmserver, kwrite and even gvim to show where they hang. ¹ Or something like that, my desktop isn't in English.
Created attachment 87407 [details] backtrace from ksmserver _name in frames #13 and #14 have this value: (QString)0xbfaa9648 (length=41): "/usr/share/applications/kde4/kate.desktop"
Created attachment 87408 [details] konsole backtrace while hung up. This is what happens when an application tries to start up. They get stuck there and never get to the point of showing a window on screen.
Created attachment 87409 [details] gvim backtrace while hung up. Even non-KDE/Qt applications are affected. gvim's backtrace (a GTK application) is very similar to konsole's.
Maybe this is a deadlock? ksmserver seems to be blocked waiting a dbus response from kwrite. But kwrite is blocked trying to connect to ksmserver to setup an X11 session.
*** Bug 343230 has been marked as a duplicate of this bug. ***
*** Bug 345315 has been marked as a duplicate of this bug. ***
This is with KDE 4.14.2 on FreeBSD 11-CURRENT: If you touch any text file in ~/.kde4/Autostart (for example a shell script without exec permissions) the complete desktop is hanging and you can not start any process or configuration windows by mouse click; I even have had running an urxvt window and when I start there a xterm process, this is just not coming up; in my case it was not kwrite, but kate which blocked soemhow the desktop: $ ls -l .kde4/Autostart/ total 8 -rw-r--r-- 1 guru wheel 4 15 may 21:03 xmod.sh this brings up some process: 4239 - I 0:00,07 kdeinit4: kdeinit4: kate -b /home/guru/.kde4/Autostart/xmod.sh (kdeini and nothing works anymore. I count this as an serious issue, because it took hours to detect the reason for an unuseable desktop, caused by just accidently created a shell script without exec bits :-( Matthias