Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 430286 - >=kde-base/konsole-4.9.0 freezes on double-click
Summary: >=kde-base/konsole-4.9.0 freezes on double-click
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo KDE team
URL: https://bugs.kde.org/show_bug.cgi?id=...
Whiteboard: tracking upstream
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-07 08:09 UTC by Martin von Gagern
Modified: 2013-10-24 18:32 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (kde-base:konsole-4.9.0.emerge--info,6.93 KB, text/plain)
2012-08-07 08:09 UTC, Martin von Gagern
Details
backtrace (gentoo430286a.bt,9.74 KB, text/plain)
2012-08-07 08:11 UTC, Martin von Gagern
Details
kded4 backtrace (kded4bt1.txt,12.24 KB, text/plain)
2012-08-11 13:29 UTC, Martin von Gagern
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin von Gagern 2012-08-07 08:09:48 UTC
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.
Comment 1 Martin von Gagern 2012-08-07 08:11:22 UTC
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.
Comment 2 Martin von Gagern 2012-08-07 10:01:19 UTC
Remerged konsole and dbus, restarted system dbus, restarted konsole, problem persists.
Comment 3 Martin von Gagern 2012-08-07 15:03:56 UTC
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.
Comment 4 Martin von Gagern 2012-08-07 15:09:30 UTC
(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.
Comment 5 Jekyll Wu 2012-08-08 03:12:25 UTC
(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
Comment 6 Johannes Huber gentoo-dev 2012-08-08 07:41:35 UTC
(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.
Comment 7 Martin von Gagern 2012-08-10 08:07:51 UTC
(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.
Comment 8 Martin von Gagern 2012-08-11 13:12:17 UTC
(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.
Comment 9 Martin von Gagern 2012-08-11 13:29:06 UTC
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.
Comment 10 Martin von Gagern 2012-08-11 17:43:01 UTC
(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.
Comment 11 Martin von Gagern 2012-09-08 18:36:55 UTC
Konsole still freezes in KDE 4.9.1
Comment 12 Thomas Bettler 2012-09-10 06:40:30 UTC
Same behaviour here with konsole-2.9.1

btw. keyboard indicator also freezes
Comment 13 Jekyll Wu 2012-09-12 08:22:23 UTC
upstream
Comment 14 Jekyll Wu 2012-09-12 08:31:10 UTC
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.
Comment 15 Martin von Gagern 2012-09-12 08:45:27 UTC
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?
Comment 16 Ole Langbehn 2012-10-11 21:18:26 UTC
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.
Comment 17 Johannes Huber gentoo-dev 2012-10-13 23:21:30 UTC
(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.
Comment 18 Michael Palimaka (kensington) gentoo-dev 2012-11-09 14:31:40 UTC
Does anyone still have this problem? The KDE developers need some more information in the upstream bug.
Comment 19 Michael Palimaka (kensington) gentoo-dev 2012-11-11 15:02:04 UTC
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?
Comment 20 Francesco Riosa 2012-11-12 22:25:57 UTC
upgraded now from 4.8.5 to 4.9.3 it's reproducible at the first selection
Comment 21 Ole Langbehn 2012-11-14 11:04:07 UTC
I can confirm that this seems to be gone after upgrading to 4.9.3
Comment 22 Mike 2012-11-20 12:30:36 UTC
konsole 4.9.3, confirmed
Comment 23 Francesco Riosa 2012-11-20 12:37:10 UTC
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
Comment 24 Mike 2012-11-21 14:15:33 UTC
after rebuild world it works fine
Comment 25 Micha 2013-01-26 19:37:41 UTC
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
Comment 26 Andreas K. Hüttel gentoo-dev 2013-02-17 22:40:36 UTC
Is anyone still seeing this with kde 4.9.5 or later?
Comment 27 Ole Langbehn 2013-02-18 08:38:42 UTC
Yep, I'm still seeing this sometimes on 4.10.0, but the frequency is bearable.
Comment 28 Johannes Huber gentoo-dev 2013-10-24 18:32:24 UTC
The offending file /usr/share/kde4/services/kded/phononserver.desktop is not installed anymore so this seems fixed.