| Summary: | kdm.log size 155MB with multiple "Invalid entry (missing ..." | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | pbea <2aq9j93b7s> |
| Component: | kdecore | Assignee: | kdelibs bugs <kdelibs-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | 2aq9j93b7s, ameretat.reith, cfeck, christoph, francisbrwn9, mpyne, nospam, oliverml1, s.wezel, serhiy.int |
| Priority: | NOR | ||
| Version First Reported In: | Git | ||
| Target Milestone: | --- | ||
| Platform: | Kubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
pbea
2014-05-15 22:26:08 UTC
Does this also happen with a freshly created user account? KDM should not try to parse files in /boot/, but that could happen with a faulty configuration. Thank You for the reply This bug maybe a symptom of other things or not! I created a new user and logged out and then back in again but opening the new user gave me an apparent frozen machine. The background wallpaper is visible. The mouse moves but absolutely nothing else works. Ctrl-Alt-Del has no effect. A power down is the only solution. I reinstalled KDM - same result. I ran sudo dpkg-reconfigure kdm - same result. The bottom line is any different user causes the machine to lockup. Any suggestions? Had this due to kdm symlinks to the latest kernel initrd.img and vmlinuz from /boot/ existing in the root / directory, and kdm not seeming to like that in a similar way to this bug? https://bugs.kde.org/show_bug.cgi?id=314759 Yes, it's definitely the same bug. Confirming for Kubuntu with kdm 4.11.11-0ubuntu0.1. And it was like that for months now. Well, I've since given up and switched to lightdm as I was fed up with huge waits for kdm to load and having to regularly clean out many GB size kdm.log files from /var/log/ due to the huge error lists this caused in those logs. Maybe 4.11.12 fixed it? Not tested to be honest. Just for info, here a possible solution: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747665 Does that mean it is a distribution bug? I have never seen this on openSUSE, btw. Depends on the point of view ... . In my case I suspect it was triggered by a (bad) operation of locale.purge, that deleted some locale-files, that should not. However the resulting behavior of the kde-runtime is maybe also discussable, like searching config files in "/" or reading binary files as config files. I think it could/should behave be a bit safer, even in a damaged, mis-configured, unspecified system environment (I know that's always easy to say, after something has happened ... so just my five cents ;). It was not easy to debug, however!) *** Bug 314759 has been marked as a duplicate of this bug. *** I've run into this off and on for years on Gentoo, with kdm ending up trying to read /bin/busybox (symlinked from /linuxrc) as a config file. I hadn't known about kde4-config trick, which reproduced the bug for me too, including this backtrace:
(gdb) bt
#0 0x00007ffff6b19d80 in __write_nocancel () from /lib64/libc.so.6
#1 0x00007ffff6ab339f in _IO_new_file_write () from /lib64/libc.so.6
#2 0x00007ffff6ab2a63 in new_do_write () from /lib64/libc.so.6
#3 0x00007ffff6ab399e in __GI__IO_file_xsputn () from /lib64/libc.so.6
#4 0x00007ffff6a8ac52 in buffered_vfprintf () from /lib64/libc.so.6
#5 0x00007ffff6a8578e in vfprintf () from /lib64/libc.so.6
#6 0x00007ffff6b3422a in __fprintf_chk () from /lib64/libc.so.6
#7 0x00007ffff787cdb1 in qt_message_output(QtMsgType, char const*) ()
from /usr/lib64/qt4/libQtCore.so.4
#8 0x00007ffff7bb2ba4 in KConfigIniBackend::printableToString(KConfigIniBackend::BufferFragment*, QFile const&, int) () from /usr/lib64/libkdecore.so.5
#9 0x00007ffff7bb30e9 in KConfigIniBackend::parseConfig(QByteArray const&, KEntryMap&, QFlags<KConfigBackend::ParseOption>, bool) () from /usr/lib64/libkdecore.so.5
#10 0x00007ffff7bb43e4 in KConfigIniBackend::parseConfig(QByteArray const&, KEntryMap&, QFlags<KConfigBackend::ParseOption>) () from /usr/lib64/libkdecore.so.5
#11 0x00007ffff7b9da1a in KConfigPrivate::parseConfigFiles() () from /usr/lib64/libkdecore.so.5
#12 0x00007ffff7b9df59 in KConfig::KConfig(QString const&, QFlags<KConfig::OpenFlag>, char const*) ()
from /usr/lib64/libkdecore.so.5
#13 0x00007ffff7cbba0f in KCurrencyCodePrivate::loadCurrency(QFileInfo const&, QString const&) ()
from /usr/lib64/libkdecore.so.5
#14 0x00007ffff7cbc623 in KCurrencyCodePrivate::KCurrencyCodePrivate(QString const&, QString const&)
() from /usr/lib64/libkdecore.so.5
#15 0x00007ffff7cbc68c in KCurrencyCode::KCurrencyCode(QString const&, QString const&) ()
from /usr/lib64/libkdecore.so.5
#16 0x00007ffff7cbc6e7 in KCurrencyCode::isValid(QString const&, QFlags<KCurrencyCode::CurrencyStatus>) () from /usr/lib64/libkdecore.so.5
#17 0x00007ffff7cc9004 in KLocalePrivate::initCurrency() () from /usr/lib64/libkdecore.so.5
#18 0x00007ffff7cd692b in KLocalePrivate::initFormat() () from /usr/lib64/libkdecore.so.5
#19 0x00007ffff7cd45a4 in KLocalePrivate::init(QString const&, QString const&, QString const&, KSharedPtr<KSharedConfig>, KConfig*) () from /usr/lib64/libkdecore.so.5
#20 0x00007ffff7d1a4bc in KLocaleUnixPrivate::KLocaleUnixPrivate(KLocale*, QString const&, KSharedPtr<KSharedConfig>) () from /usr/lib64/libkdecore.so.5
---Type <return> to continue, or q <return> to quit---
#21 0x00007ffff7cc5fbd in KLocale::KLocale(QString const&, KSharedPtr<KSharedConfig>) ()
from /usr/lib64/libkdecore.so.5
#22 0x00007ffff7c47783 in KGlobal::locale() () from /usr/lib64/libkdecore.so.5
#23 0x00007ffff7cdffd1 in KLocalizedString::toString() const () from /usr/lib64/libkdecore.so.5
#24 0x00007ffff7c3ffb3 in KCmdLineArgsStatic::findOption(QByteArray const&, QByteArray const&, int&, bool, bool&) () from /usr/lib64/libkdecore.so.5
#25 0x00007ffff7c436c0 in KCmdLineArgsStatic::parseAllArgs() () from /usr/lib64/libkdecore.so.5
#26 0x00007ffff7c4428a in KCmdLineArgs::parsedArgs(QByteArray const&) ()
from /usr/lib64/libkdecore.so.5
#27 0x0000000000402af2 in main ()
I'm not exactly sure what's going on here, my working guess was that we tried to open a currency code desktop entry (in share/locale/currency) that didn't exist, but that doesn't explain how we end up reading symlinked and completely un-related files. Even still, the following patch (against KDE4 kdelibs) seems to avert further issues for me:
diff --git a/kdecore/localization/kcurrencycode.cpp b/kdecore/localization/kcurrencycode.cpp
index c406014..dd1c0c9 100644
--- a/kdecore/localization/kcurrencycode.cpp
+++ b/kdecore/localization/kcurrencycode.cpp
@@ -107,6 +107,10 @@ KCurrencyCodePrivate::~KCurrencyCodePrivate()
void KCurrencyCodePrivate::loadCurrency( const QFileInfo ¤cyCodeFile, const QString &language )
{
+ if ( !currencyCodeFile.exists() ) {
+ return;
+ }
+
KConfig cgFile( currencyCodeFile.absoluteFilePath() );
// If language is empty, means to stick with the global default, which is the default for any new KConfig
Maybe failing to load a currency code causes a chain of events that leads to searching within the current working directory for other potential config files? (E.g. the file being read is "linuxrc" in my case -- a possible config file). I'm not sure myself, but if this patch works I'll likely commit to KDE4 and see about forward porting.
This isn't a KDM bug, kdm is just the innocent victim here. *** Bug 216627 has been marked as a duplicate of this bug. *** I don't think this stiff applies to KF 5 or 6. |