Description of problem: konsole freezes for about a minute the first time one right clicks a selection. This happens in startx, also in a new user, as well as on all of JWM, Xfce, and Plasma 5. After a while, konsole wakes up from the freeze and then one can right click a selection quickly. Furthermore, restarting konsole causes the symptoms to reoccur on the next session. My machine is: ``` My primary machine is a desktop machine with a: An Intel Core i3 CPU (x86-64). 8 GB of RAM. Intel Corporation Sandy Bridge Integrated Graphics Controller (rev 09) A 2 TB hard-disk. A 21â³ Wide LCD Screen by LG. Intel Corporation Cougar Point High Definition Audio Controller. Intel Corporation 82579V Gigabit Network Connection. ``` It also happens with konsole built from the git master source into a prefix. Version-Release number of selected component (if applicable): Cauldron. How reproducible: Always. Steps to Reproduce: 1. Use startx as a new user. 2. Start konsole 3. double click to make a selection. 4. right click when the cursor is on the selection to invoke the context menu. Reproducible: Steps to Reproduce:
valid also for: Mageia-6-dev1-LiveDVD-PLASMA5-x86_64-DVD.iso DATE.txt: Sun Jan 17 19:30:00 CET 2016
CC: (none) => westel
Hi Ben, (In reply to ben mcmonagle from comment #1) > valid also for: > > Mageia-6-dev1-LiveDVD-PLASMA5-x86_64-DVD.iso > DATE.txt: Sun Jan 17 19:30:00 CET 2016 thanks for the update. On which hardware did you test it? Not all people can reproduce it. Regards, -- Shlomi Fish
hardware details: Asus P8B75-M LX Intel B75 mATX Ivy Bridge Socket 1155 2xDDR3-2200 USB3.0 SATA3 Onboard VGA/DVI Intel Core i5-3470 CPU @ 3.20GHz Kingston 4GB DDR3 1600MHz Non-ECC CL11 DIMM KVR16N11/4 x 2 WD5000AAKX WD Caviar Blue 500GB SATA3 6Gb/s HDD, 16MB Cache, 7200RPM x 2 HCC54505 Hitachi 500GB SATA 3.0Gb/s 5400RPM , Seagate 160GB 3 160812AS SATA II 7200rpm Barracuda 7200.9 SATA x 2 LG Black SATA DVDWriterx20/22 Supermulti GH20NS10BBK
invoked konsole from "run command" alt+F2
(In reply to ben mcmonagle from comment #4) > invoked konsole from "run command" alt+F2 Thanks for the details.
Hi all, some updates: 1. I can reproduce the problem again and again if I start konsole under gdb with the --nofork flag. 2. After capturing the gdb stack trace, I wrote a small KDE frameworks 5 (KF5) program to reproduce the symptoms of the problem: https://github.com/shlomif/KF5-KUriFilter-Test-for-Konsole-Bug it involves waiting a long time for the calls to return as well which is unacceptable. Regards, -- Shlomi Fish
here is the backtrace from the kurifilter-test's mytest.exe: (gdb) bt full #0 0x00007ffff56b6c3f in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007ffff6dbbd0b in QWaitCondition::wait(QMutex*, unsigned long) (time=18446744073709551615, this=0x82f970) at thread/qwaitcondition_unix.cpp:136 code = <optimized out> #2 0x00007ffff6dbbd0b in QWaitCondition::wait(QMutex*, unsigned long) (this=this@entry=0x88b200, mutex=mutex@entry=0x88b1f8, time=time@entry=18446744073709551615) at thread/qwaitcondition_unix.cpp:208 #3 0x00007ffff1d4af94 in QDBusPendingCallPrivate::waitForFinished() (this=this@entry=0x88b1c0) at qdbuspendingcall.cpp:234 locker = {val = 8958457} #4 0x00007ffff1d0967e in QDBusConnectionPrivate::sendWithReply(QDBusMessage const&, int, int) (this=this@entry=0x7fffc00026d0, message=..., sendMode=sendMode@entry=1, timeout=timeout@entry=-1) at qdbusintegrator.cpp:1901 watcher = {m_message = {d_ptr = 0x82f900}, m_maxCallTimeoutMs = -1, m_callTimer = {t1 = 6264, t2 = 664663509}} pcall = 0x88b1c0 reply = {d_ptr = 0x7fffffffcbcf} #5 0x00007ffff1d09d1f in QDBusConnectionPrivate::findMetaObject(QString const&, QString const&, QString const&, QDBusError&) (this=0x7fffc00026d0, service=..., path=..., interface=..., error=...) at qdbusintegrator.cpp:2394 msg = {d_ptr = 0x82f900} reply = {d_ptr = 0x7fffffffcbcf} locker = <optimized out> mo = <optimized out> xml = {static null = {<No data fields>}, d = 0x0} result = <optimized out> #6 0x00007ffff1d14cb5 in QDBusInterfacePrivate::QDBusInterfacePrivate(QString const&, QString const&, QString const&, QDBusConnection const&) (this=0x88b4e0, serv=..., p=..., iface=..., con=...) at qdbusinterface.cpp:150 #7 0x00007ffff1d14e25 in QDBusInterface::QDBusInterface(QString const&, QString const&, QString const&, QDBusConnection const&, QObject*) (this=0x7fffffffcd60, service=..., path=..., interface=..., connection=..., parent=0x0) at qdbusinterface.cpp:212 #8 0x00007ffff361dc66 in KIO::favIconForUrl(QUrl const&) (url=...) at /usr/src/debug/kio-5.18.0/src/core/global.cpp:338 iconNameCache = {{d = 0x7ffff7042760 <QHashData::shared_null>, e = 0x7ffff7042760 <QHashData::shared_null>}} autoClearCache = 0 notFound = {static null = {<No data fields>}, d = 0x7ffff365ebc0 <KIO::favIconForUrl(QUrl const&)::{lambda()#1}::operator()() const::qstring_literal>} iconNameFromCache = {static null = {<No data fields>}, d = 0x7ffff365ebc0 <KIO::favIconForUrl(QUrl const&)::{lambda()#1}::operator()() const::qstring_literal>} kded = {<QDBusAbstractInterface> = {<QDBusAbstractInterfaceBase> = {<QObject> = {_vptr.QObject = 0x18, static staticMetaObject = {d = {superdata = 0x0, stringdata = 0x7ffff70e2920 <qt_meta_stringdata_QObject>, data = 0x7ffff70e2800 <---Type <return> to continue, or q <return> to quit--- qt_meta_data_QObject>, static_metacall = 0x7ffff6fadaf0 <QObject::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)>, relatedMetaObjects = 0x0, extradata = 0x0}}, d_ptr = {d = 0x7ffff388f0c0 <KIO::favIconForUrl(QUrl const&)@got.plt>}, static staticQtMetaObject = {d = {superdata = 0x0, stringdata = 0x7ffff712a480 <qt_meta_stringdata_Qt>, data = 0x7ffff7127a00 <qt_meta_data_Qt>, static_metacall = 0x0, relatedMetaObjects = 0x0, extradata = 0x0}}}, <No data fields>}, static staticMetaObject = {d = {superdata = 0x7ffff71b7780 <QObject::staticMetaObject>, stringdata = 0x7ffff1d519c0 <qt_meta_stringdata_QDBusAbstractInterface>, data = 0x7ffff1d51940 <qt_meta_data_QDBusAbstractInterface>, static_metacall = 0x7ffff1d10590 <QDBusAbstractInterface::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)>, relatedMetaObjects = 0x0, extradata = 0x0}}}, <No data fields>} result = {m_error = {code = 3221235408, msg = {static null = {<No data fields>}, d = 0x7fff00000001}, nm = {static null = {<No data fields>}, d = 0x7fffffffce90}, unused = 0x7fffffffcea0}, m_data = {static null = {<No data fields>}, d = 0x1}} #9 0x00007ffff361e64d in KIO::iconNameForUrl(QUrl const&) (url=...) at /usr/src/debug/kio-5.18.0/src/core/global.cpp:356 db = {d = 0x7ffff71c68c0 <(anonymous namespace)::Q_QGS_staticQMimeDatabase::innerFunction()::holder>} mt = {d = {d = 0x88b420}} unknown = {m_size = 7, m_data = 0x7ffff365eac5 "unknown"} mimeTypeIcon = {static null = {<No data fields>}, d = 0x88ce40} i = {static null = {<No data fields>}, d = 0x88ce40} #10 0x00007fffd47f5cf2 in SearchProvider::iconName() const (this=<optimized out>) at /usr/src/debug/kio-5.18.0/src/urifilters/ikws/searchprovider.cpp:111 #11 0x00007ffff6aa3a2a in KUriFilterData::iconNameForPreferredSearchProvider(QString const&) const (this=<optimized out>, provider=...) at /usr/src/debug/kio-5.18.0/src/widgets/kurifilter.cpp:381 #12 0x000000000040204b in main(int, char**) (argc=1, argv=0x7fffffffd258) at kf5-kurifilterdata-test.cpp:47 s = {static null = {<No data fields>}, d = 0x842890} i = 0 application = {<QGuiApplication> = {<QCoreApplication> = {<QObject> = {_vptr.QObject = 0x7ffff7dacc08 <vtable for QApplication+16>, static staticMetaObject = {d = {superdata = 0x0, stringdata = 0x7ffff70e2920 <qt_meta_stringdata_QObject>, data = 0x7ffff70e2800 <qt_meta_data_QObject>, static_metacall = 0x7ffff6fadaf0 <QObject::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)>, relatedMetaObjects = 0x0, extradata = 0x0}}, d_ptr = {d = 0x622c20}, static staticQtMetaObject = {d = {superdata = 0x0, stringdata = 0x7ffff712a480 <qt_meta_stringdata_Qt>, data = 0x7ffff7127a00 <qt_meta_data_Qt>, static_metacall = 0x0, relatedMetaObjects = 0x0, extradata = 0x0}}}, static staticMetaObject = {d = {superdata = 0x7ffff71b7780 <QObject::staticMetaObject>, stringdata = 0x7ffff71410a0 <qt_meta_stringdata_QCoreApplication>, data = 0x7ffff7140f80 <qt_meta_data_QCoreApplication>, static_metacall = 0x7ffff701cd50 <QCoreApplication::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)>, relatedMetaObjects = 0x0, extradata = 0x0}}, static self = 0x7fffffffcfc0}, static staticMetaObject = {d = {superdata = 0x7ffff71c0420 <QCoreApplication::staticMetaObject>, stringdata = 0x7ffff769da60 ---Type <return> to continue, or q <return> to quit--- <qt_meta_stringdata_QGuiApplication>, data = 0x7ffff769d820 <qt_meta_data_QGuiApplication>, static_metacall = 0x7ffff72c7030 <QGuiApplication::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)>, relatedMetaObjects = 0x0, extradata = 0x0}}}, static staticMetaObject = {d = {superdata = 0x7ffff77691a0 <QGuiApplication::staticMetaObject>, stringdata = 0x7ffff7c5e720 <qt_meta_stringdata_QApplication>, data = 0x7ffff7c5e5a0 <qt_meta_data_QApplication>, static_metacall = 0x7ffff78dd750 <QApplication::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)>, relatedMetaObjects = 0x0, extradata = 0x0}}} aboutData = {d = 0x811e00} parser = {d = 0x8137b0} data = {d = 0x83d0f0} filtered = true l = {<QList<QString>> = {<QListSpecialMethods<QString>> = {<No data fields>}, {p = {static shared_null = {ref = {atomic = {_q_value = -1}}, alloc = 0, begin = 0, end = 0, array = {0x0}}, d = 0x842840}, d = 0x842840}}, <No data fields>} (gdb)
Here is a chat log on #kde-devel about it: Jan 30 13:14:34 <rindolf> Hi all. Can anyone tell me why this KUriFilter program is so time consuming on my Mageia Linux x86-64 v6 system? See https://bugs.mageia.org/show_bug.cgi?id=17590 and https://github.com/shlomif/KF5-KUriFilter-Test-for-Konsole-Bug . let me know how I can help. Jan 30 13:25:02 <dfaure> rindolf: it's fast here Jan 30 13:26:01 <dfaure> you should post the gdb stacktrace into the report Jan 30 13:27:14 <dfaure> rindolf: and here's a contribution, porting your Makefile to qmake so it works with custom kf5 install prefixes too: http://www.davidfaure.fr/2016/0001-Port-to-qmake.patch Jan 30 13:48:36 <rindolf> dfaure: OK. Jan 30 13:50:37 <rindolf> dfaure: I am getting <<kf5-kurifilterdata-test.cpp:8:24: fatal error: kurifilter.h: No such file or directory>> - reverting. Jan 30 13:50:55 <dfaure> hold on ;) Jan 30 13:51:13 <dfaure> hmm that's in KIOWidgets, so the .pro is correct Jan 30 13:52:25 <dfaure> I guess your kf5 .pri files didn't get installed where qmake is looking (I have $QMAKEPATH set for this); anyway, side issue. Jan 30 13:54:54 <rindolf> dfaure: see https://bugs.mageia.org/show_bug.cgi?id=17590#c7 Jan 30 13:55:27 <dfaure> ah! excellent Jan 30 13:55:31 <dfaure> it's exactly what I'm working on Jan 30 13:55:36 <dfaure> (moving favicons away from dbus) Jan 30 13:56:16 <dfaure> your kded seems to be stuck btw Jan 30 13:56:23 <dfaure> attach gdb to kded5 to see what it's doing Jan 30 13:56:28 <dfaure> it's what this is calling into Jan 30 13:56:30 <rindolf> dfaure: ah. Jan 30 13:57:28 <rindolf> dfaure: I see: shlomif 3316 0.0 0.6 811988 48580 ? Sl 12:16 0:00 /usr/bin/kded5 Jan 30 13:57:28 <rindolf> shlomif 4780 0.0 0.5 803880 41068 ? Sl 12:33 0:00 /usr/bin/kded5 Jan 30 13:57:35 <rindolf> dfaure: which one is it? Jan 30 13:57:54 <dfaure> the only way you can have two is if you have two dbus sessions... Jan 30 13:58:41 <dfaure> (or if maybe the second is the fork of the first, use "ps awwlx" to get the parent pid too, but I don't think it actually forks anymore) Jan 30 14:00:13 <rindolf> dfaure: they both have a PPID of 1. Jan 30 14:00:29 <dfaure> how many dbus-daemon running (with --session) ? Jan 30 14:03:05 <rindolf> dfaure: http://paste.debian.net/377588/ - see this. Jan 30 14:03:24 <dfaure> in other words, 1 Jan 30 14:04:01 <dfaure> something's not kosher Jan 30 14:04:27 <dfaure> oh wait kded5 doesn't exit if already running? weird Jan 30 14:04:52 <dfaure> ah it does, it's the stupid deadlock in Breeze::StylePlugin::~StylePlugin again Jan 30 14:05:00 <dfaure> well attach gdb to both, you'll see what they are both doing ;) Jan 30 14:05:28 <rindolf> dfaure: OK. Jan 30 14:05:31 <rindolf> sigh. Jan 30 14:07:10 <rindolf> dfaure: here's one - http://www.shlomifish.org/Files/files/text/kded5-out1.txt Jan 30 14:07:41 <dfaure> lol it's waiting for klauncher .... nice chain Jan 30 14:08:47 <rindolf> dfaure: here's the second - http://www.shlomifish.org/Files/files/text/kded5-out2.txt Jan 30 14:09:16 <dfaure> in fact the first kded is just waiting for the dbus daemon to tell it if a given service is registered. If that blocks, it must be a problem with dbus itself... Jan 30 14:09:37 <dfaure> second is the same Jan 30 14:10:20 <rindolf> dfaure: all of this just to use the freaking konsole! Jan 30 14:10:41 <dfaure> yep, see why I'm removing the dependencies to kded more and more ;) Jan 30 14:11:05 <rindolf> dfaure: thanks for that. Jan 30 14:11:26 <dfaure> rindolf: does `qdbus` work? Jan 30 14:12:24 <rindolf> dfaure: it gives me this output - http://www.shlomifish.org/Files/files/text/qdbus-out-1.txt Jan 30 14:12:41 <dfaure> notice: only one kded5 ;) Jan 30 14:12:59 <dfaure> (I wish qdbus would also print the PID....) Jan 30 14:14:43 <dfaure> strange though, I don't see why QDBusConnectionInterface::isServiceRegistered would block, and `qdbus` would work Jan 30 14:15:46 <dfaure> if you run kded5 again, it hangs too? Jan 30 14:16:51 <dfaure> oh you have Qt 5.6, QtDBus has gone through quite some changes there.... Jan 30 14:17:32 <dfaure> make sure you have a1ba281 in qtbase Jan 30 14:17:43 <dfaure> (although the symptoms wouldn't be exactly this) Jan 30 14:21:56 <rindolf> dfaure: what is a1ba281? Jan 30 14:22:10 <rindolf> dfaure: a version control checksum? Jan 30 14:22:15 <dfaure> the sha1 of a commit in qtbase which unbreaks qt5.6's dbus for kded's usage Jan 30 14:22:32 <dfaure> are you compiling qtbase from sources? Jan 30 14:22:57 <rindolf> dfaure: no, I'm not - I'm using the Mageia packages. Jan 30 14:23:12 <dfaure> then which qt 5.6 does that provide? beta1 or something? Jan 30 14:23:37 <rindolf> dfaure: qtbase5-common-5.6.0-0.beta.8.mga6 Jan 30 14:23:45 <dfaure> just perfect Jan 30 14:23:49 <dfaure> let's make packages of beta versions Jan 30 14:23:53 <dfaure> and then users will get bugs Jan 30 14:23:56 <dfaure> :) Jan 30 14:24:22 <rindolf> dfaure: well, it's Cauldron, so it's the bleeding-edge distribution. Jan 30 14:24:29 <dfaure> clearly Jan 30 14:24:33 <dfaure> well, happy bleeding then ;) Jan 30 14:24:40 <rindolf> dfaure: OK. Jan 30 14:24:46 <dfaure> but it's pointless to debug this further without a more recent qt 5.6 Jan 30 14:24:54 <rindolf> dfaure: ah. Jan 30 14:25:03 <dfaure> meanwhile if you restart your session it would work again, I would think Jan 30 14:25:15 <rindolf> dfaure: what would work again? Jan 30 14:25:20 <dfaure> dbus calls ;) Jan 30 14:25:23 <rindolf> dfaure: and which session? Jan 30 14:25:23 <dfaure> i.e. rmb in konsole Jan 30 14:25:30 <rindolf> dfaure: ah. Jan 30 14:25:39 <dfaure> plasma session, to get a new dbus and only one kded5 etc. ;) Jan 30 14:25:40 <rindolf> dfaure: I restarted them several times. Jan 30 14:25:49 <rindolf> dfaure: I'm on Xfce. Jan 30 14:26:08 <dfaure> then xfce session ;) Jan 30 14:26:13 <dfaure> whatever starts the dbus daemon Jan 30 14:26:27 <dfaure> see, I'm not sure exactly what's happening. I see two possibilities Jan 30 14:26:27 <rindolf> dfaure: well, restarting causes the problem to reemerge. Jan 30 14:26:44 <dfaure> hmm ok Jan 30 14:27:03 <dfaure> if you could try with qt 5.5 we could eliminate the possibility that it's a QtDBus regression Jan 30 14:27:24 <dfaure> but I suppose you can't select qt version Jan 30 14:28:05 <rindolf> dfaure: I can try installing it under a prefix and using LD_LIBRARY_PATH Jan 30 14:28:55 <dfaure> correct, but you'd need to make sure that even dbus-daemon sees this LD_LIBRARY_PATH, because some kde processes are autostarted via dbus Jan 30 14:37:23 <rindolf> dfaure: ah. Jan 30 14:39:12 <dfaure> leaving now, email me with results ;) Jan 30 14:52:42 <rindolf> Hi all. Where can I find the patch for a1ba281 ? Google, DuckDuckGo and https://code.qt.io/cgit/qt/qt5.git/commit/ are no help. Jan 30 14:55:25 <kensington> rindolf: maybe https://code.qt.io/cgit/qt/qtbase.git/commit/?id=a1ba281 Jan 30 15:01:47 <rindolf> kensington: thanks! But it doesn't apply cleanly.
Blocks: (none) => 17523
Assignee: bugsquad => mageia
Update: on a latest Mageia x86-64 Cauldron/v6, the symptoms of the reported problem appear to be gone on my machine (desktop, Core i3). I tried it in Xfce in my main user and in jwm in a new user - first right click is quite snappy . Another thing to note is that my test program on GitHub also runs quickly enough. ben: does it work for you as well?
seems ok in Plasma5 x86. i will wait for new .isos and recheck then.
ok in : Mageia-6-dev1-LiveDVD-PLASMA5-x86_64-DVD.iso DATE.txt: Sun Feb 28 07:30:00 CET 2016 and Mageia-6-dev1-LiveDVD-PLASMA5-i586-DVD.iso DATE.txt: Sun Feb 28 07:30:00 CET 2016 recommend resolved: fixed
Resolving as fixed because it's fine here too.
Status: NEW => RESOLVEDResolution: (none) => FIXED