Bug 235081

Summary: warn when running out of diskspace in /var/tmp, now this causes kde system crashes (krunner, kwin, plasma-desktop,...)
Product: [Frameworks and Libraries] kdelibs Reporter: Chris <christian.andi>
Component: kdeuiAssignee: kdelibs bugs <kdelibs-bugs>
Status: RESOLVED FIXED    
Severity: crash CC: cfeck, ender, lukas.karas, mpyne, p92
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In: 4.5.0
Attachments: New crash information added by DrKonqi
New crash information added by DrKonqi

Description Chris 2010-04-22 17:33:10 UTC 
Version:            (using KDE 4.4.2)
OS:                Linux
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
[KCrash Handler]
#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
/usr/lib/libkdeui.so.5
#7  0x00007ffb82465838 in KPixmapCache::recreateCacheFiles() () from
/usr/lib/libkdeui.so.5
#8  0x00007ffb824659b5 in KPixmapCache::Private::checkFileVersion(QString
const&) () from /usr/lib/libkdeui.so.5
#9  0x00007ffb824639f0 in KPixmapCache::Private::init() () from
/usr/lib/libkdeui.so.5
#10 0x00007ffb82463b79 in KPixmapCache::timestamp() const () from
/usr/lib/libkdeui.so.5
#11 0x00007ffb81e96c8c in Plasma::ThemePrivate::setThemeName(QString const&,
bool) () from /usr/lib/libplasma.so.3
#12 0x00007ffb81e96f7b in Plasma::Theme::settingsChanged() () from
/usr/lib/libplasma.so.3

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!
Christian
Comment 1 Christoph Feck 2010-04-22 17:51:48 UTC 
Michael, how does current/new KPixmapCache handle disk full situations? It should not crash.
Comment 2 Michael Pyne 2010-04-23 02:56:43 UTC 
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!
Comment 3 Chris 2010-04-24 13:41:19 UTC 
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
[KCrash Handler]
#6  0xb77c0cee in KPixmapCache::Private::mmapFile (this=0x8174f00, filename=@0x8174f14, info=0x8174f34, newsize=33656832)
    at /mnt/data/tmp/paludis/kde-base-kdelibs-4.4.2/work/kdelibs-4.4.2/kdeui/util/kpixmapcache.cpp:495
#7  0xb77c2454 in KPixmapCache::Private::mmapFiles (this=0x8174f00) at 
/mnt/data/tmp/paludis/kde-base-kdelibs-4.4.2/work/kdelibs-4.4.2/kdeui/util/kpixmapcache.cpp:420
#8  0xb77c187e in KPixmapCache::recreateCacheFiles (this=0x8176230) at 
/mnt/data/tmp/paludis/kde-base-kdelibs-4.4.2/work/kdelibs-4.4.2/kdeui/util/kpixmapcache.cpp:1266
#9  0xb77c1bab in KPixmapCache::Private::checkFileVersion (this=0x8174f00, filename=@0x8174f18) at 
/mnt/data/tmp/paludis/kde-base-kdelibs-4.4.2/work/kdelibs-4.4.2/kdeui/util/kpixmapcache.cpp:757
#10 0xb77c2113 in KPixmapCache::Private::init (this=0x8174f00) at 
/mnt/data/tmp/paludis/kde-base-kdelibs-4.4.2/work/kdelibs-4.4.2/kdeui/util/kpixmapcache.cpp:1070
#11 0xb77c2245 in KPixmapCache::ensureInited (this=0x8176230) at 
/mnt/data/tmp/paludis/kde-base-kdelibs-4.4.2/work/kdelibs-4.4.2/kdeui/util/kpixmapcache.cpp:1087
#12 0xb77c2313 in KPixmapCache::timestamp (this=0x8176230) at 
/mnt/data/tmp/paludis/kde-base-kdelibs-4.4.2/work/kdelibs-4.4.2/kdeui/util/kpixmapcache.cpp:1120


Application: KDE Accessibility Tool (kdeinit4), signal: Bus error
[KCrash Handler]
#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)
    at /mnt/data/tmp/paludis/kde-base-kdelibs-4.4.2/work/kdelibs-4.4.2/kdeui/util/kpixmapcache.cpp:843
#13 0xb77c43dd in KPixmapCache::Private::writeIndex (this=0x8136748, key=@0xbfd1cb44, dataoffset=536040)
    at /mnt/data/tmp/paludis/kde-base-kdelibs-4.4.2/work/kdelibs-4.4.2/kdeui/util/kpixmapcache.cpp:1499
#14 0xb77c44e1 in KPixmapCache::insert (this=0x81366b0, key=@0xbfd1cdbc, pix=@0xbfd1cd90) at 
/mnt/data/tmp/paludis/kde-base-kdelibs-4.4.2/work/kdelibs-4.4.2/kdeui/util/kpixmapcache.cpp:1446
#15 0xb76fe7bc in KIconCache::insert (this=0x81366b0, key=@0xbfd1cdbc, pix=@0xbfd1cd90) at 
/mnt/data/tmp/paludis/kde-base-kdelibs-4.4.2/work/kdelibs-4.4.2/kdeui/icons/kiconcache.cpp:298
#16 0xb76f2e50 in KIconLoader::loadIcon (this=0x80a9500, _name=@0xbfd1d100, group=KIconLoader::User, size=32, state=0, overlays=@0x80ccc1c, 
path_store=0x0, canReturnNull=true)
    at /mnt/data/tmp/paludis/kde-base-kdelibs-4.4.2/work/kdelibs-4.4.2/kdeui/icons/kiconloader.cpp:1005
#17 0xb76f39e2 in KIconLoader::loadIcon (this=0x80a9500, _name=@0x80ccc18, group=KIconLoader::Desktop, size=32, state=0, overlays=@0x80ccc1c, 
path_store=0x0, canReturnNull=false)

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).
Comment 4 David Martínez Moreno 2010-05-12 09:27:56 UTC 
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.
Comment 5 p92 2010-07-24 12:14:10 UTC 
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.
Comment 6 Christoph Feck 2010-10-14 00:27:47 UTC 
(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
Comment 7 Lukáš Karas 2011-01-11 00:10:45 UTC 
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 :)
Comment 8 Christoph Feck 2011-01-11 00:38:00 UTC 
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?
Comment 9 Lukáš Karas 2011-01-11 23:26:22 UTC 
(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