Version: 1.2.50 (KDE 4.1.60) (using Devel) Installed from: Compiled sources Compiler: gcc version 4.3.1 (Debian 4.3.1-8) OS: Linux If you launch akregator with the --nofork command line option you will notice that it doesn't start immediately. It waits for ~30 seconds, then it shows the system tray icon (which is black at the point), then it waits for another ~30 seconds and then it opens akregator. This doesn't happen if you launch akregator without "--nofork". I tried to debug this in gdb by interrupting it while it waits and I got the backtrace below. It seems like it waits for some dbus feedback which never comes and times out. It's not really a serious bug as akregator normally starts with no command line options, but it is irritating if you are trying to debug something inside gdb, where you have to use --nofork. Backtrace: Program received signal SIGINT, Interrupt. [Switching to Thread 0x7f7f5b6f0780 (LWP 2598)] 0x00007f7f537c5d5f in poll () from /lib/libc.so.6 (gdb) bt #0 0x00007f7f537c5d5f in poll () from /lib/libc.so.6 #1 0x00007f7f4d235a98 in ?? () from /usr/lib/libdbus-1.so.3 #2 0x00007f7f4d233ed4 in ?? () from /usr/lib/libdbus-1.so.3 #3 0x00007f7f4d220dae in ?? () from /usr/lib/libdbus-1.so.3 #4 0x00007f7f4d22306c in ?? () from /usr/lib/libdbus-1.so.3 #5 0x00007f7f4d2220fc in dbus_connection_send_with_reply_and_block () from /usr/lib/libdbus-1.so.3 #6 0x00007f7f554bd074 in q_dbus_connection_send_with_reply_and_block (connection=0x6c7080, message=0x6cd8a0, timeout_milliseconds=-1, error=0x7fff6382e5a0) at ./qdbus_symbols_p.h:120 #7 0x00007f7f554c5e2f in QDBusConnectionPrivate::sendWithReply (this=0x6c5520, message=@0x7fff6382e890, sendMode=1, timeout=-1) at qdbusintegrator.cpp:1681 #8 0x00007f7f554c63e9 in QDBusConnectionPrivate::findMetaObject (this=0x6c5520, service=@0x7790e8, path=@0x7790f8, interface=@0x779100, error=@0x779108) at qdbusintegrator.cpp:2000 #9 0x00007f7f554d2eed in QDBusInterfacePrivate (this=0x779060, serv=@0x7fff6382ebe0, p=@0x7fff6382ebd0, iface=@0x7fff6382ebc0, con=@0x7fff6382ebb0) at qdbusinterface.cpp:62 #10 0x00007f7f554d2fd9 in QDBusInterface (this=0x7fff6382eba0, service=@0x7fff6382ebe0, path=@0x7fff6382ebd0, interface=@0x7fff6382ebc0, connection=@0x7fff6382ebb0, parent=0x0) at qdbusinterface.cpp:123 #11 0x0000000000408768 in Akregator::Application::newInstance (this=0x7fff6382fbd0) at /home/gkiagia/kde/src/KDE/kdepim/akregator/src/main.cpp:52 #12 0x00007f7f581e9c6c in KUniqueApplication::Private::_k_newInstanceNoFork (this=0x776c10) at /home/gkiagia/kde/src/KDE/kdelibs/kdeui/kernel/kuniqueapplication.cpp:394 #13 0x00007f7f581e9cde in KUniqueApplication::qt_metacall (this=0x7fff6382fbd0, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fff6382eeb0) at /home/gkiagia/kde/build/KDE/kdelibs/kdeui/kuniqueapplication.moc:65 #14 0x00007f7f57131b84 in QMetaObject::activate (sender=0x776b10, from_signal_index=4, to_signal_index=4, argv=0x0) at kernel/qobject.cpp:3013 #15 0x00007f7f57131ff9 in QMetaObject::activate (sender=0x776b10, m=0x7f7f574197c0, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3086 #16 0x00007f7f5713b68c in QSingleShotTimer::timeout (this=0x776b10) at .moc/debug-shared/qtimer.moc:74 #17 0x00007f7f5713b783 in QSingleShotTimer::timerEvent (this=0x776b10) at kernel/qtimer.cpp:300 #18 0x00007f7f5712fe38 in QObject::event (this=0x776b10, e=0x7fff6382f7e0) at kernel/qobject.cpp:1105 #19 0x00007f7f558ea71d in QApplicationPrivate::notify_helper (this=0x6cdb10, receiver=0x776b10, e=0x7fff6382f7e0) at kernel/qapplication.cpp:3800 #20 0x00007f7f558eaa39 in QApplication::notify (this=0x7fff6382fbd0, receiver=0x776b10, e=0x7fff6382f7e0) at kernel/qapplication.cpp:3392 #21 0x00007f7f581e47a2 in KApplication::notify (this=0x7fff6382fbd0, receiver=0x776b10, event=0x7fff6382f7e0) at /home/gkiagia/kde/src/KDE/kdelibs/kdeui/kernel/kapplication.cpp:311 #22 0x00007f7f5711d707 in QCoreApplication::notifyInternal (this=0x7fff6382fbd0, receiver=0x776b10, event=0x7fff6382f7e0) at kernel/qcoreapplication.cpp:587 #23 0x00007f7f5aac2757 in QCoreApplication::sendEvent (receiver=0x776b10, event=0x7fff6382f7e0) at ../../../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215 #24 0x00007f7f5714d89d in QTimerInfoList::activateTimers (this=0x6d1010) at kernel/qeventdispatcher_unix.cpp:563 #25 0x00007f7f5714b0e2 in timerSourceDispatch (source=0x6d0fb0) at kernel/qeventdispatcher_glib.cpp:166 #26 0x00007f7f5152d892 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #27 0x00007f7f5153101d in ?? () from /usr/lib/libglib-2.0.so.0 #28 0x00007f7f515311db in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #29 0x00007f7f5714a33e in QEventDispatcherGlib::processEvents (this=0x6c5870, flags={i = 1669528128}) at kernel/qeventdispatcher_glib.cpp:325 #30 0x00007f7f5598947b in QGuiEventDispatcherGlib::processEvents (this=0x6c5870, flags={i = 1669528224}) at kernel/qguieventdispatcher_glib.cpp:204 #31 0x00007f7f5711a96b in QEventLoop::processEvents (this=0x7fff6382fb50, flags={i = 1669528320}) at kernel/qeventloop.cpp:149 #32 0x00007f7f5711ab66 in QEventLoop::exec (this=0x7fff6382fb50, flags={i = 1669528416}) at kernel/qeventloop.cpp:196 #33 0x00007f7f5711df6c in QCoreApplication::exec () at kernel/qcoreapplication.cpp:849 #34 0x00007f7f558ea47a in QApplication::exec () at kernel/qapplication.cpp:3330 #35 0x000000000040a2f8 in main (argc=2, argv=0x7fff6382fd58) at /home/gkiagia/kde/src/KDE/kdepim/akregator/src/main.cpp:115
Those delays happen when Application::newInstance() tries to set-up connection to the D-Bus interface for loading up the feedlist and stuff. Tried to see around what could cause it, but didn't find any apparent reason for it. According to QDbusConnection's isConnected() we at least have a connection.. Calling qdbus org.kde.akregator causes qdbus to freeze also after displaying only '/'. Tried to move loadPart() call before creation of the QDBusInterface for it, but that didn't help. QDBusConnection::sessionBus().registerObject() in Part::Part() for that interface returns true though. Anyways, for me this sounds more like a bug in KUniqueApplication than in Akregator. What do you think Frank?
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of akregator (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.