Application: kded4 ($Id$) KDE Platform Version: 4.8.4 (4.8.4) Qt Version: 4.8.1 Operating System: Linux 3.2.0-30-generic i686 Distribution: Linux Mint 13 Maya -- Information about the crash: - What I was doing when the application crashed: mint 13 KDE I changed my keyboard model to the correct one in Keyboard settings. -- Backtrace: Application: KDE Daemon (kdeinit4), signal: Aborted Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0xb777f740 (LWP 1518))] Thread 4 (Thread 0xb3df0b40 (LWP 1521)): #0 0x079b7c64 in __pthread_mutex_unlock_usercnt () from /lib/i386-linux-gnu/libpthread.so.0 #1 0x0047b634 in pthread_mutex_unlock () from /lib/i386-linux-gnu/libc.so.6 #2 0x03a64410 in g_mutex_unlock () from /lib/i386-linux-gnu/libglib-2.0.so.0 #3 0x03a24f50 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #4 0x03a25201 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #5 0x00b2d8e7 in QEventDispatcherGlib::processEvents (this=0xb3400468, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #6 0x00af950d in QEventLoop::processEvents (this=0xb3df0250, flags=...) at kernel/qeventloop.cpp:149 #7 0x00af97a9 in QEventLoop::exec (this=0xb3df0250, flags=...) at kernel/qeventloop.cpp:204 #8 0x009e294c in QThread::exec (this=0x9737448) at thread/qthread.cpp:501 #9 0x06cfb757 in ?? () from /usr/lib/kde4/kded_bluedevil.so #10 0x009e5de0 in QThreadPrivate::start (arg=0x9737448) at thread/qthread_unix.cpp:298 #11 0x079b4d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #12 0x0046dace in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 3 (Thread 0xb33ffb40 (LWP 1526)): #0 0x079b3483 in __i686.get_pc_thunk.bx () from /lib/i386-linux-gnu/libpthread.so.0 #1 0x079b6cbf in pthread_mutex_lock () from /lib/i386-linux-gnu/libpthread.so.0 #2 0x0047b5f4 in pthread_mutex_lock () from /lib/i386-linux-gnu/libc.so.6 #3 0x03a643d0 in g_mutex_lock () from /lib/i386-linux-gnu/libglib-2.0.so.0 #4 0x03a24b85 in g_main_context_check () from /lib/i386-linux-gnu/libglib-2.0.so.0 #5 0x03a25042 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #6 0x03a25201 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #7 0x00b2d8e7 in QEventDispatcherGlib::processEvents (this=0xb2a00468, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #8 0x00af950d in QEventLoop::processEvents (this=0xb33ff240, flags=...) at kernel/qeventloop.cpp:149 #9 0x00af97a9 in QEventLoop::exec (this=0xb33ff240, flags=...) at kernel/qeventloop.cpp:204 #10 0x009e294c in QThread::exec (this=0x98d35d8) at thread/qthread.cpp:501 #11 0x00ad6b5d in QInotifyFileSystemWatcherEngine::run (this=0x98d35d8) at io/qfilesystemwatcher_inotify.cpp:248 #12 0x009e5de0 in QThreadPrivate::start (arg=0x98d35d8) at thread/qthread_unix.cpp:298 #13 0x079b4d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #14 0x0046dace in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 2 (Thread 0xb21feb40 (LWP 1682)): #0 0x00539416 in __kernel_vsyscall () #1 0x0045f380 in poll () from /lib/i386-linux-gnu/libc.so.6 #2 0x03a32a7b in g_poll () from /lib/i386-linux-gnu/libglib-2.0.so.0 #3 0x03a250ae in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #4 0x03a2556b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0 #5 0x038811ba in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0 #6 0x03a486b3 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #7 0x079b4d4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0 #8 0x0046dace in clone () from /lib/i386-linux-gnu/libc.so.6 Thread 1 (Thread 0xb777f740 (LWP 1518)): [KCrash Handler] #7 0x00539416 in __kernel_vsyscall () #8 0x003b11ef in raise () from /lib/i386-linux-gnu/libc.so.6 #9 0x003b4835 in abort () from /lib/i386-linux-gnu/libc.so.6 #10 0x003ec2fa in ?? () from /lib/i386-linux-gnu/libc.so.6 #11 0x00482dd5 in __fortify_fail () from /lib/i386-linux-gnu/libc.so.6 #12 0x00481baa in __chk_fail () from /lib/i386-linux-gnu/libc.so.6 #13 0x00482d6a in __fdelt_warn () from /lib/i386-linux-gnu/libc.so.6 #14 0x00ad2443 in QProcessPrivate::waitForStarted (this=0x9aae6b0, msecs=-1) at io/qprocess_unix.cpp:1038 #15 0x00a86e94 in QProcess::waitForStarted (this=0xbf9d1ba4, msecs=-1) at io/qprocess.cpp:1687 #16 0x00a86fc4 in QProcess::waitForFinished (this=0xbf9d1ba4, msecs=-1) at io/qprocess.cpp:1752 #17 0x00d88292 in KProcess::execute (this=0xbf9d1ba4, msecs=-1) at ../../kdecore/io/kprocess.cpp:350 #18 0x03716414 in XkbHelper::runConfigLayoutCommand (setxkbmapCommandArguments=...) at ../../../kcontrol/keyboard/xkb_helper.cpp:108 #19 0x03717bc2 in XkbHelper::initializeKeyboardLayouts (config=...) at ../../../kcontrol/keyboard/xkb_helper.cpp:178 #20 0x03708b2e in KeyboardDaemon::configureKeyboard (this=0x98ec1c8) at ../../../kcontrol/keyboard/keyboard_daemon.cpp:100 #21 0x03707650 in qt_static_metacall (_a=0xbf9d1ecc, _id=4, _o=0x98ec1c8, _c=<optimized out>) at moc_keyboard_daemon.cpp:79 #22 KeyboardDaemon::qt_static_metacall (_o=0x98ec1c8, _c=QMetaObject::InvokeMetaMethod, _id=4, _a=0xbf9d1ecc) at moc_keyboard_daemon.cpp:69 #23 0x0370778c in KeyboardDaemon::qt_metacall (this=0x98ec1c8, _c=QMetaObject::InvokeMetaMethod, _id=<optimized out>, _a=0xbf9d1ecc) at moc_keyboard_daemon.cpp:129 #24 0x061fba38 in QDBusConnectionPrivate::deliverCall (this=0x9774788, object=0x98ec1c8, msg=..., metaTypes=..., slotIdx=0) at qdbusintegrator.cpp:947 #25 0x06205c8d in QDBusCallDeliveryEvent::placeMetaCall (this=0x9aaee58, object=0x98ec1c8) at qdbusintegrator_p.h:103 #26 0x00b15c7b in QObject::event (this=0x98ec1c8, e=0x9aaee58) at kernel/qobject.cpp:1195 #27 0x0109aed4 in notify_helper (e=0x9aaee58, receiver=0x98ec1c8, this=0x9777950) at kernel/qapplication.cpp:4559 #28 QApplicationPrivate::notify_helper (this=0x9777950, receiver=0x98ec1c8, e=0x9aaee58) at kernel/qapplication.cpp:4531 #29 0x010a030d in QApplication::notify (this=0x9aaee58, receiver=0x98ec1c8, e=0x9aaee58) at kernel/qapplication.cpp:4288 #30 0x00727401 in KApplication::notify (this=0xbf9d2710, receiver=0x98ec1c8, event=0x9aaee58) at ../../kdeui/kernel/kapplication.cpp:311 #31 0x00afa97e in QCoreApplication::notifyInternal (this=0xbf9d2710, receiver=0x98ec1c8, event=0x9aaee58) at kernel/qcoreapplication.cpp:876 #32 0x00afead8 in sendEvent (event=<optimized out>, receiver=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231 #33 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x9708a40) at kernel/qcoreapplication.cpp:1500 #34 0x00afee0c in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1393 #35 0x00b2d494 in sendPostedEvents () at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:236 #36 postEventSourceDispatch (s=0x9778d80) at kernel/qeventdispatcher_glib.cpp:279 #37 0x03a24d86 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0 #38 0x03a25125 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #39 0x03a25201 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #40 0x00b2d887 in QEventDispatcherGlib::processEvents (this=0x9709dc8, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #41 0x01153aaa in QGuiEventDispatcherGlib::processEvents (this=0x9709dc8, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #42 0x00af950d in QEventLoop::processEvents (this=0xbf9d2674, flags=...) at kernel/qeventloop.cpp:149 #43 0x00af97a9 in QEventLoop::exec (this=0xbf9d2674, flags=...) at kernel/qeventloop.cpp:204 #44 0x00afeeba in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1148 #45 0x01098a74 in QApplication::exec () at kernel/qapplication.cpp:3820 #46 0x059be959 in kdemain (argc=1, argv=0x9757198) at ../../kded/kded.cpp:924 #47 0x0804f8a4 in launch (argc=<optimized out>, _name=0x8052607 "kded4", args=<optimized out>, cwd=0x0, envc=0, envs=<optimized out>, reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x805248e "0") at ../../kinit/kinit.cpp:746 #48 0x0804c9df in main (argc=<error reading variable: Cannot access memory at address 0x5ee>, argv=<error reading variable: Cannot access memory at address 0x5f2>, envp=<error reading variable: Cannot access memory at address 0x5f6>) at ../../kinit/kinit.cpp:1861 Possible duplicates by query: bug 303814, bug 287932. Reported using DrKonqi
This may be caused by a downstream kded module, such as the package update notifier. If this is reproducible, please check which kded module causes the crash by disabling them. For more information, see http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/
*** Bug 307262 has been marked as a duplicate of this bug. ***
*** Bug 294682 has been marked as a duplicate of this bug. ***
*** Bug 304301 has been marked as a duplicate of this bug. ***
If you can provide the information requested in comment #1, please add it.
*** Bug 299471 has been marked as a duplicate of this bug. ***
*** Bug 307829 has been marked as a duplicate of this bug. ***
*** Bug 308466 has been marked as a duplicate of this bug. ***
*** Bug 308481 has been marked as a duplicate of this bug. ***
*** Bug 308960 has been marked as a duplicate of this bug. ***
*** Bug 309128 has been marked as a duplicate of this bug. ***
*** Bug 309295 has been marked as a duplicate of this bug. ***
*** Bug 309348 has been marked as a duplicate of this bug. ***
*** Bug 309355 has been marked as a duplicate of this bug. ***
*** Bug 310392 has been marked as a duplicate of this bug. ***
*** Bug 311040 has been marked as a duplicate of this bug. ***
*** Bug 311748 has been marked as a duplicate of this bug. ***
*** Bug 311772 has been marked as a duplicate of this bug. ***
*** Bug 313361 has been marked as a duplicate of this bug. ***
We still lack the information requested in comment #1. Since no KDE developer can reproduce the issue, it is believed to be caused by a third-party kded module. Please report this bug to the bugtracker of your distribution, or add the information we need.
I only noticed that bug #314031 had been marked duplicate after I posted a response there (at Milian Wolff's request). I posted output from my terminal in my comment #8. It seems it only confirms what you have discovered here though.
I'm in the process of turning off some kded4 modules in Service Manager. Its still crashing for me but I got something a little different at the end of my console output this time that I thought I'd pass on: --Terminal output QFile::remove: Empty or null file name QFile::remove: Empty or null file name (process:1291): GLib-ERROR **: Creating pipes for GWakeup: Too many open files --End terminal output Quick question. When you stop services in Service Manager and click apply does that restart kded4?
I disabled all my Service Manager listed modules. Killed kded4 and restarted it with "kdeinit4 kded4" (but I did not do a kbuildsycoca4. Missed that part). Kdevelop still crashed as soon as the session had loaded. Next I removed usr/share/kde4/services/kded/ and restarted my system. I've since been able to load several large KDevelop sessions without a single crash. I'm going to try and work using it with the desktop in this crippled mode for a bit to see if it occurs a bit latter. If not I'll put the kded4 service folder back and see if I can start isolating the culprit.
*** Bug 315194 has been marked as a duplicate of this bug. ***
*** Bug 318669 has been marked as a duplicate of this bug. ***
*** Bug 318896 has been marked as a duplicate of this bug. ***
Adam, any success finding the kded module that leaks file descriptors? This should ideally be solved before the Ubuntu distribution switches to Qt 4.8.5, where leaked file descriptors are silently ignored, causing much more obscure behavior with all other modules.
Unfortunately (kind of :-/) I can no longer produce this bug. I am still using KDevelop heavily but it has been rock solid for a while now. Note that I am using the update and backport PPAs for Kubuntu. I was not sure if a work around had been released or not. I've not changed any of my plugins so I doubt it was anything I did except run updates. I know it was mentioned (maybe by yourself) that KDevelop is leaking file descriptors (a Qt bug from what I read). So I don't know if this is technically fixed or not? Plus I see similar reports are still coming in. I'm still on Quantal (with Qt 4.8.3) and won't be moving to Raring for a couple weeks so I'll do my best to keep an eye out for the bug but it does seem gone for me.
Adam, the KDevelop issue is fixed already, what I am interested in is kded4.
Sorry I did not read your post well enough Christoph. I was unable to find a specific Kded module that caused problems for me. I tried various combinations. My problems went away with the KDevelop updates (#314031). I don't know if there was a module that leaked file descriptors or whether having kded off just left me with so many free file descriptors it allowed KDevelop to function at the time but I did (eventually) still get a crash in KDevelop at the time related to the file descriptor issue there even with Kded disabled. So I'm not sure if I was ever truly effected by this specific bug.
*** Bug 322782 has been marked as a duplicate of this bug. ***
*** Bug 323711 has been marked as a duplicate of this bug. ***
*** Bug 323830 has been marked as a duplicate of this bug. ***
*** Bug 327574 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
I cannot reproduce the bug (KDE Daemon crash after resume from suspend-to-RAM) but it occurs (seemingly randomly) from time to time. I read in http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/ that "for crashes, the offending module can often be found in the complete backtrace." Can the offending module be found in the backtrace that I attached to bug 327574?
No, unfortunately not. The issue here is that one of the kded modules forgets to close a file handle. Over the time, the process runs out of them. The crash occurs because QProcess tries to get a new file descriptor, but did not handle the failure. This does not really make it a Qt bug, though. Since Qt 4.8.5, QProcess does no longer crash, but this will make the situation only worse: Failures to allocating file handles will now be silently ignored, causing other bugs at all modules. That's why it would be crucial to find the offending module before Ubuntu updates to Qt 4.8.5. To debug this more efficiently, one would somehow need to change the limit of available file descriptors for the kded4 process, so that it runs out of them earlier. Or maybe there are ways to monitor the number of allocated handles over time. Then finding the offending kded module by disabling it should become simpler. Try starting with package update notifiers modules, or any other distribution-supplied modules, because with a stock KDE, we never had this issue.
To do as Christoph says, limiting number of available FDs, one can make a wrapper script for kded4, like this one: #!/bin/bash ulimit -n MaxFDs # place some small value instead of MaxFDs (default on Ubuntu is 1024) kded4.real "$@" , which would be put in place of original kded4, and original one would be renamed to kded4.real.
I'll chime in to confirm that it seems quite hard to debug this issue with Qt 4.8.5 . I'm running KDE 4.12.4 from MacPorts on OS X 10.6, and when I launch kded4 it starts complaining about too many open files almost immediately. From playing with the content in /opt/local/share/applications/kde4 and /opt/local/share/kde4/services/kded it would appear that there is no particular culprit, but that it's the number of entries in those (and a handful other?) directories that determine how many files kded4 opens. For giggles: on my OS X machine, kded4 has over 2600 files open before it's even completely initialised; on a Linux box running the same KDE version with a session open since a couple of days, it is just over 300 files (which is still a lot IMHO).