Version: (using KDE 4.4.2)
Installed from: Gentoo Packages
I had a problem that was not easy to find, kde worked correct for a long time (only minor program crashes) but some day after emerging an app and some packages one to another kde system application (e.g. plasma-desktop, kwin, krunner, ...) crashed. I logged out and tried to log in, but kde did not start anymore, kwin crashed with a backtrace like this:
Application: KWin (kwin), signal: Bus error
#5 0x00007ffb8246308b in KPixmapCache::Private::mmapFile(QString const&,
KPixmapCache::Private::MmapInfo*, int) () from /usr/lib/libkdeui.so.5
#6 0x00007ffb82463c78 in KPixmapCache::Private::mmapFiles() () from
#7 0x00007ffb82465838 in KPixmapCache::recreateCacheFiles() () from
#8 0x00007ffb824659b5 in KPixmapCache::Private::checkFileVersion(QString
const&) () from /usr/lib/libkdeui.so.5
#9 0x00007ffb824639f0 in KPixmapCache::Private::init() () from
#10 0x00007ffb82463b79 in KPixmapCache::timestamp() const () from
#11 0x00007ffb81e96c8c in Plasma::ThemePrivate::setThemeName(QString const&,
bool) () from /usr/lib/libplasma.so.3
#12 0x00007ffb81e96f7b in Plasma::Theme::settingsChanged() () from
Afterward I installed the newest kde packages (kde-4.4.2, before it was kde-4.4.1) but that did not resolve the problem. So I searched the internet using some keywords of the backtrace and found this bug report: https://bugs.kde.org/show_bug.cgi?id=233127.
The user had the problem that /var/tmp runned out of space, so I looked on my /var/tmp/ partition and df showed 100% usage, 0 free. After cleaning up /var/tmp, kde started up flawless and all problems disappeared.
It took me several hours to find the problem, so it would be nice if kde warns the user when /var/tmp/kdecache-USER directory runs out of space! It would be also nice if all routines writing to a full directoy would show an error saying something like "Out of diskspace: please free some space in /var/tmp/ to continue <RETRY>" instead of crashing. I think it would save much time for other people and eliminate some bugs related to this.
Thank you all for the great KDE!
Michael, how does current/new KPixmapCache handle disk full situations? It should not crash.
I can't tell you in general how KPC responds to disk full situations (although I can't imagine it handles that case properly in general). However, I've just taken a quick look at KPixmapCache::Private::mmapFile() (where the crash appears) and all the file handling code seems to be checking the result of the open/resize methods.
Perhaps Linux optimistically allows the resize to complete even if the partition is already full, or perhaps there's a different bug altogether but I don't see an exceptionally quick/easy fix. Maybe once I get time to do more thorough debugging (including simulating full partitions) I can narrow it down further.
My upcoming cache replacement checks return codes as well but it would probably still be susceptible to this issue.
Honestly I think the best solution is to have kdeinit4 or kded4 check for this on startup and dump some files if the partition is full (perhaps Solid can be used to determine the amount of space free?). This has the concern that we'd need to be very sure that no one has mapped /var/tmp to /home or something silly like that though!
I made some disk full situation tests. If kde is started after disk is already full (and /var/tmp/kdecache directory was removed before) then the startup aborts with message 'Call to lnusertemp failed (temporary directories full?). But if termporary diretory gets full while kde is running (because some additional programs are started and need caching or other programs write to /var/tmp) then kde applications are crashing: (here are 2 example backtraces generated by this situations on my kde)
Application: KMix (kdeinit4), signal: Bus error
#6 0xb77c0cee in KPixmapCache::Private::mmapFile (this=0x8174f00, filename=@0x8174f14, info=0x8174f34, newsize=33656832)
#7 0xb77c2454 in KPixmapCache::Private::mmapFiles (this=0x8174f00) at
#8 0xb77c187e in KPixmapCache::recreateCacheFiles (this=0x8176230) at
#9 0xb77c1bab in KPixmapCache::Private::checkFileVersion (this=0x8174f00, filename=@0x8174f18) at
#10 0xb77c2113 in KPixmapCache::Private::init (this=0x8174f00) at
#11 0xb77c2245 in KPixmapCache::ensureInited (this=0x8176230) at
#12 0xb77c2313 in KPixmapCache::timestamp (this=0x8176230) at
Application: KDE Accessibility Tool (kdeinit4), signal: Bus error
#6 0xb654e021 in memcpy () from /lib/libc.so.6
#7 0xb77c02e7 in writeData (this=0xbfd1c610, data=0xbfd1c610 "", len=4) at /usr/include/bits/string3.h:52
#8 0xb73548e0 in QIODevice::write () from /usr/lib/qt4/libQtCore.so.4
#9 0xb733e4c7 in QDataStream::operator<< () from /usr/lib/qt4/libQtCore.so.4
#10 0xb733e546 in QDataStream::writeBytes () from /usr/lib/qt4/libQtCore.so.4
#11 0xb730d4cb in operator<< () from /usr/lib/qt4/libQtCore.so.4
#12 0xb77c0612 in KPixmapCache::Private::writeIndexEntry (this=0x8136748, stream=@0xbfd1caf0, key=@0xbfd1cb44, dataoffset=536040)
#13 0xb77c43dd in KPixmapCache::Private::writeIndex (this=0x8136748, key=@0xbfd1cb44, dataoffset=536040)
#14 0xb77c44e1 in KPixmapCache::insert (this=0x81366b0, key=@0xbfd1cdbc, pix=@0xbfd1cd90) at
#15 0xb76fe7bc in KIconCache::insert (this=0x81366b0, key=@0xbfd1cdbc, pix=@0xbfd1cd90) at
#16 0xb76f2e50 in KIconLoader::loadIcon (this=0x80a9500, _name=@0xbfd1d100, group=KIconLoader::User, size=32, state=0, overlays=@0x80ccc1c,
#17 0xb76f39e2 in KIconLoader::loadIcon (this=0x80a9500, _name=@0x80ccc18, group=KIconLoader::Desktop, size=32, state=0, overlays=@0x80ccc1c,
I think all KPixmapCache routines should check the disk state and pause or abort their caching operation (with user warning, I think there should be ways determining directory space state e.g. df -h DIRECTORY found a way).
Created attachment 43506 [details]
New crash information added by DrKonqi
Same problem here. /var full and KDE starts to die inexplicably. I am used to these situations and remembered to look at df -h.
Created attachment 49452 [details]
New crash information added by DrKonqi
Another backtrace of krunner in the same situation (/ full while kde is running).
Other application that crash on suc a condition : plasma-destop, krdc
a warning on FS nearly full for FS important to kde would be a great integration as well as not crashing if possible.
(I quickly reviewed the backtrace of this crash, and it appears to be caused by KIconCache memory corruption. If this is not the case, please reopen.)
Closing all KIconCache crashes as fixed, because the KIconLoader in KDE SC 4.5 now uses KSharedDataCache to cache icons, and it is believed that the new class is less prone to random crashes or memory corruption.
If you still can reproduce a crash with version 4.5, please report it separately. If you cannot upgrade to 4.5 yet, you should be able to work around this crash by deleting the icon cache files in /var/tmp/kdecache-<user>/kpc
Please, reopen this bug. This problem is not solved! I mean that it isn't problem of kdeui component, but kio problem (or kdelibs generally?). Its cache (directory /var/tmp/kdecache-$USER) can overfill disk quotas in some use cases (tens gigabytes in my case).
It should exist some mechanism for cleaning this cache - avoid disk overfill!
Please, I don't want download large files via wget anymore. I want to use kio :)
This bug initially was about a crash when the icon cache files could not be created. I am not sure if a separate bug should be reported for the issue you are seeing.
Which file or sub-directory of /var/temp/kdecache-user grows that large without ever getting deleted? Is there a way to reproduce it reliably?
(In reply to comment #8)
> This bug initially was about a crash when the icon cache files could not be
> created. I am not sure if a separate bug should be reported for the issue you
> are seeing.
> Which file or sub-directory of /var/temp/kdecache-user grows that large without
> ever getting deleted? Is there a way to reproduce it reliably?
I create new bug report after some research... 262906