Created attachment 320600 [details] emerge --info Whenever I double-click into a konsole window in order to select a word, the process freezes. I see no updates from the commands in any of my konsole windows, and they don't respond to input either. I can open a new window, but it takes forever, and the new window will remain white with no prompt, even though my konsole theme uses semi-transparent dark background. Today is the first time I experience this issue. Yesterday I did a few updates, and had to downgrade udev from 187 to 171-r6 due to bug #430002. Not sure whether that has anything to do with this bug here.
Created attachment 320602 [details] backtrace Attaching gdb to the frozen process, I find one thread blocked somewhere talking to dbus, whereas a second thread is waiting in select. Not sure whether this is of any value.
Remerged konsole and dbus, restarted system dbus, restarted konsole, problem persists.
Some more debugging, using strace: … 4171 16:30:24.473207 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC, 0) = 6 4171 16:30:24.476303 connect(6, {sa_family=AF_FILE, sun_path=@"/tmp/dbus-etp8lILNFP"}, 23) = 0 … 4171 16:30:44.691143 sendmsg(6, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0{\0\0\0\1\1o\0\21\0\0\0/modules/favicons\0\0\0\0\0\0\0\6\1s\0\f\0\0\0org.kde.kded\0\0\0\0\2\1s\0#\0\0\0org.freedesktop.DBus.Introspectable\0\0\0\0\0\3\1s\0\n\0\0\0Introspect\0\0\0\0\0\0", 144}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 144 4171 16:30:44.691196 poll([{fd=6, events=POLLIN}], 1, 25000) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) 4171 16:31:04.138007 --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} --- I did my double-click at 16:30:4* and waited a long while for things to settle. Then I pressed a key. That key didn't register at all, as konsole was no longer listening to the X11 socket connection. Neither did any mouse events register. The first thing to reach console after that piece of code was thje SIGINT when I pressed Ctrl+C to interrupt strace. So I'd say the problem really lies somewhere in this dbus communication, just as the backtrace suggested. The other thread doesn't appear to be responsible for dealing with X events. Just starting konsole from xterm, I see two copies of this message: QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. So perhaps it is just this kind of misbehaviour I'm seeing here. In another strace run, I saw a number of poll timeouts intermixed with re-requests of some favicon-related dbus message, followed by a lot of stat and access calls for files related to mime type configuration, and ending with the poll quoted above. There had been 50 seconds between the first sendmsg calls and the final poll which got interrupted by sigint. No dbus response was ever received. So this might have something to do with dbus not responding in general. I'll try to log out and in, see if that fixes anything.
(In reply to comment #3) > I'll try to log out and in, see if that fixes anything. Yes, now everything works as it should. It seems that something went wrong with session initialization last time around: apparently dbus wasn't running properly, and logout failed as well; I had to kill my X server. Probably due to dbus as well. This kind of logout problem I've seen before, it's not new in KDE 4.9.0 but annoying nevertheless.
(In reply to comment #3) > Just starting konsole from xterm, I see two copies of this message: > > QDBusConnection: session D-Bus connection created before QCoreApplication. > Application may misbehave. > > So perhaps it is just this kind of misbehaviour I'm seeing here. > FYI, that warning happens to every KDE application using class KUniqueApplication since Qt 4.8 . AFAIK, there is not any real bug caused by that warning. See https://bugs.kde.org/show_bug.cgi?id=297020
(In reply to comment #5) > > FYI, that warning happens to every KDE application using class > KUniqueApplication since Qt 4.8 . AFAIK, there is not any real bug caused by > that warning. See https://bugs.kde.org/show_bug.cgi?id=297020 Thanks, we will track this problem.
(In reply to comment #3) > So I'd say the problem really lies somewhere in this dbus communication, Hit this again today. It appears that some parts of my KDE session didn't start either: I'm lacking my volume control as well as my klipboard tool tray items. Not sure where the common cause to all of these lies. There are three dbus-related processes running on my system: /usr/bin/dbus-daemon --system dbus-launch --sh-syntax --exit-with-session /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session Of these, the last one appears to be the one konsole is talking to. I did a simultaneous strace of both that process and konsole. It seems that dbus forwards the message to some other connection. Unfortunately I haven't found out how to identify the other end of an open unix domain socket connection. I know what file descriptor dbus-daemon is writing to, but not what other process should be reading that message and acting on it.
(In reply to comment #5) > AFAIK, there is not any real bug caused by that warning. In that case, I'd prefer for this bug report here to concentrate on the very real bug I'm observing. Feel free to open another report to keep track of that message, but I'm not concerned about the message itself, but about my konsole freezing on a regular basis. More than 50% of my sessions lately, which makes it pretty much unusable. (In reply to comment #7) > Unfortunately I haven't found out how to identify the other end of an open > unix domain socket connection. I used http://stackoverflow.com/a/11900231/1468366 to identify the other end. It'd kded4 which is holding that connection. So konsole writes something to dbus and then blocks waiting for an answer. As a reaction to that, dbus writes something to kded4. And kded4 has four threds, all of them waiting on input from one or more file descriptors, but NONE of them waiting for input from that particular file descriptor. So I'd say it's kded4 which is misbehaving, by not reading from an open connection, and it's a problem in konsole that it handles the lack of a response so badly.
Created attachment 321004 [details] kded4 backtrace This is a backtrace of all four threads of kded4. Thread 1 is waiting for FD 19 (a pipe) Thread 2 is waiting for FDs 18 and 17 (both anon_inode) Thread 3 is waiting for FDs 14, 13 and 15 (two anon_inode and one unix socket) Thread 4 is waiting for FD 4 according to strace (a pipe) FD 5 is the one where the message from dbus is waiting. FD 13 is a connection to dbus, but it's the system bus, not the session bus.
(In reply to comment #9) FD 11 is another connection to the session dbus, which isn't been listened upon either. There are no other connections to the session dbus. So unless there is some strange timeout-driven alteration between sources to listen to, I'd assume that kded is not listening to the session dbus at all. Reading https://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/ tells me that kded employs the same sort of insanity already afflicting plasma: they bunch together a number of unrelated code pieces into one binary, so that if one of them fails, all the others go down with it. Given that my bug can only be reproduced probabilistically, not with any certainty, debuggung that feels like a really big problem. Probably won't be able to make any more progress on this for the next 3 weeks, as I'll be away most of the time. One more piece of information: In the backtrace of konsole attached to comment #1, pay particular attention to frame #12. There the details of the dbus call are visible: QDBusInterface kded( QString::fromLatin1("org.kde.kded"), QString::fromLatin1("/modules/favicons"), QString::fromLatin1("org.kde.FavIcon") ); QDBusReply<QString> result = kded.call( QString::fromLatin1("iconForUrl"), url.url() ); I guess the "url" is the word I double-clicked, so you may well assume that to be "foo". With these parameters, it should be possible to dublicate the dbus request and trace how it SHOULD behave on a working system.
Konsole still freezes in KDE 4.9.1
Same behaviour here with konsole-2.9.1 btw. keyboard indicator also freezes
upstream
Sorry for the previous comment sent by accident. I don't understand why https://bugs.kde.org/show_bug.cgi?id=297020 was set as the upstream report for this report after comment #5. My intention was the opposite. That dbus warning for every KDE application using class KUniqueApplication, AFAIK, has not been confirmed to cause any real bug on bugs.kde.org. Now there is https://bugs.kde.org/show_bug.cgi?id=306338 for the same problem. Please set that as the upstream bug.
Some additional information on this whole issue: I'm not sure, but I have the impression that this error is more likely to occur when I log into my session as soon as the login screen appears. At that time, the boot process hasn't completed yet, and OpenRC is still starting services in the background. It might well be that the absence of some service is responsible for the failure of some kded module, and therefore the unresponsiveness of kded as a whole. If so, adding a service dependency might work around this issue, although I still consider the current behaviour of kded inherently broken. I'm currently experimenting with different combinations of enabled KDE services. Changes there seem to have an effect, but given the problems in reproducing this issue at all, it will take more time to narrow this down to the one service actually causing this bug. (In reply to comment #14) > Now there is https://bugs.kde.org/show_bug.cgi?id=306338 for the same > problem. Please set that as the upstream bug. Thanks for the link! Set the URL accordingly. I also removed the "tracking upstream" whiteboard message. That upstream report suggests that this issue is very specific to Gentoo, so simply waiting for KDE devs to resolve it might not be the best course. If "tracking upstream" has some other meaning for you, feel free to re-add that. Seeing that the upstream report has at least two more people affected by this, would you mark this report here as CONFIRMED?
I'm hit by this, too. I use konsole under xmonad, with as little kde components as possible. It happened reproducably every time I selected text and every time it took about 1/2h to unlock again. downgraded to 4.8.5, issue is gone. Tell me if/how I can help.
(In reply to comment #16) > I'm hit by this, too. I use konsole under xmonad, with as little kde > components as possible. It happened reproducably every time I selected text > and every time it took about 1/2h to unlock again. > > downgraded to 4.8.5, issue is gone. > > Tell me if/how I can help. Please contribute to upstream bug.
Does anyone still have this problem? The KDE developers need some more information in the upstream bug.
Someone reported in the upstream bug that it is fixed for them with 4.9.2. Can someone who had this problem please test and report back?
upgraded now from 4.8.5 to 4.9.3 it's reproducible at the first selection
I can confirm that this seems to be gone after upgrading to 4.9.3
konsole 4.9.3, confirmed
by the way on this system the the hung was caused by the favicon service, removing /usr/share/kde4/services/kded/favicons.desktop fixed it. There is a related review requst on "kde-core-devel" mail-list, title of the message "Review Request: favicon local cache" citing kde bugs 306338, 307973
after rebuild world it works fine
Just posted here: https://bugs.kde.org/show_bug.cgi?id=306338 I had the click-to-freeze-konsole-bug. Solution for me: I removed /usr/share/kde4/services/kded/phononserver.desktop --> bug fixed. I shortened /usr/share/kde4/services/kded/phononserver.desktop (removed all translations except [de]) --> bug fixed! Looks like some text parsing in this config file is not working. My system: Gentoo, Kernel 3.6.11, 64bit, KDE 4.9.3
Is anyone still seeing this with kde 4.9.5 or later?
Yep, I'm still seeing this sometimes on 4.10.0, but the frequency is bearable.
The offending file /usr/share/kde4/services/kded/phononserver.desktop is not installed anymore so this seems fixed.
