| Summary: | KDE runtime libraries are by default in noisy debug mode to stdout/stderr | ||
|---|---|---|---|
| Product: | [I don't know] kde | Reporter: | Matti Aarnio <matti.aarnio--kde> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | eric.brunet, esigra, faure, gentoo.integer, kdelibs-bugs, kevin.kofler, matti.aarnio--kde, modax, oliver.henshaw, rdalek1967, rdieter, realnc, stu, tomas.linhart, tomas |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Matti Aarnio
2010-02-15 23:52:19 UTC
I had the same problem and a little research led me to the page http://techbase.kde.org/Development/FAQs/Debugging_FAQ#Is_there_a_preferred_way_to_print_debug_output_on_stderr.3F Indeed, running kdebugdialog allowed me to disable all output. HOWEVER something has changed between kde 4.3.5 and 4.4.0. To my understanding, /usr/share/config/kdebugrc controls debug output, but this file does not list, for instance, (in either kde) bug area 7011 (KSycoca) which is the source of some of the messages in the original bug report. So it seems the default in 4.3.5 is to NOT output any debug info in an area which is not explicitely mentioned, while the default in 4.4.0 is to output debug info by default. Why the change in behaviour ? Is it tunable by some config file ? With kdebugdialog used to disable everything it knows about, and then killing all KDE related processed before restarting the application: $ ktorrent Warning: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) kdeinit4: preparing to launch /usr/lib64/libkdeinit4_klauncher.so Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) kdeinit4: preparing to launch /usr/lib64/libkdeinit4_kded4.so kdeinit4: preparing to launch /usr/lib64/libkdeinit4_kbuildsycoca4.so kbuildsycoca4 running... kdeinit4: preparing to launch /usr/lib64/libkdeinit4_kconf_update.so Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) Warning: Calling appendChild() on a null node does nothing. Warning: Calling appendChild() on a null node does nothing. Warning: Calling appendChild() on a null node does nothing. $ Well, it is better than previous, but not truly silenced. At least kdeinit4 and kbuildsycoca4 should be silent. Same here on Gentoo AMD64, KDE 4.4.0. The current default behavior blows the .xsession-errors file out of proportions (definitely not a Good Thing) and makes launching KDE apps from Konsole a big mess. By default everything should be silent on non-debug builds. People who need debug output should opt-in with kdebugdialog. Thanks for the kdebugdialog tip! Anyhow, I agree that silence should be default. With everything unticked in kdebugdialog, there is still a lot of kde-related stuff in .xsession-errors. I had a little dig around to see why and came up with a couple of findings: * Sometimes this is deliberate - e.g. kdelibs/kinit/kinit.cpp:launch uses fprintf rather than the kdebug infrastructure. * Sometimes this is accidental - some code is using debug areas that aren't found in /usr/share/config/kdebug.areas - and so the debug console spew remains on. A couple of examples are * kdebase/runtime/kglobalaccel/globalshortcutsregistry.cpp:GlobalShortcutsRegistry::registerKey A debug area is not specified here, but KDE_DEFAULT_DEBUG_AREA=181 was set in CMakeLists.txt. This debug area was a holdover from past times and it looks like the problem has been fixed in trunk. * kdebase/runtime/knotify/knotify.cpp:KNotify::event hard-codes a debug area of 300. This isn't currently defined in kdebug.areas but I haven't looked to see whether it's a typo or code rot or what. first step: admit you have a problem. :) (confirmed). I fixed the bug about unknown debug areas recently in trunk (r1102343) and I might have a fix for the overall problem of default behavior in release mode, please test http://www.davidfaure.fr/2010/kdebug.cpp.defaultoutput.diff knotify is fixed too. SVN commit 1105394 by dfaure: Fix the disabling of debug output when compiling apps in release mode. Found a way to unittest it after all: calling hasNullOutput directly. CCBUG: 227089 M +3 -3 io/kdebug.cpp M +27 -0 tests/kdebug_unittest.cpp M +1 -0 tests/kdebug_unittest.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1105394 SVN commit 1105396 by dfaure: Backport r1105394: Fix the disabling of debug output when compiling apps in release mode. Fixed for: 4.4.2 BUG: 227089 M +3 -3 io/kdebug.cpp M +27 -0 tests/kdebug_unittest.cpp M +1 -0 tests/kdebug_unittest.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1105396 I can confirm that due to the commit above the problem no longer exists in 4.4 branch. SVN commit 1125871 by lunakl: When writing to kdebugrc whether debug output is enabled or disabled, do so only for kDebug(), since kWarning() etc. are enabled even in release build. This prevents debug output from getting enabled by default in release builds when an app calls kWarning() before first kDebug(). CCBUG: 227089 M +1 -1 kdebug.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1125871 SVN commit 1125875 by lunakl: Backport: When writing to kdebugrc whether debug output is enabled or disabled, do so only for kDebug(), since kWarning() etc. are enabled even in release build. This prevents debug output from getting enabled by default in release builds when an app calls kWarning() before first kDebug(). CCBUG: 227089 M +1 -1 kdebug.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1125875 |