do you have sth. called "bleachbit" installed?

No, I don't have "bleachbit" installed.

Do you think that it may be caused by a deletion of a file somewhere in /tmp or /var/tmp? I use systemd init daemon and there is tmp files cleaner service active, which may delete files in those directories (if older than 10days in /tmp or 30days in /var/tmp) - I think, however, that kwin crashed earlier than this.

Anyway, should I look for something specific? Before crash and after it, than?

Since the crash occured when inserting a shared data pixmap, a garbled (deleting would not be problematic - overwriting is) SHM buffer in /var/tmp/kdecache-`whoami` is a reasonable candidate (and we had that with bleachbit ... a lot)

Other options would be:
- defect HDD sector (badblocks, fsck)
- out of disk space (df -h)
- bug in kshareddatacache

> Since the crash occured when inserting a shared data pixmap, a garbled (deleting would not be problematic - overwriting is) SHM buffer in /var/tmp/kdecache-`whoami` is a reasonable candidate (and we had that with bleachbit ... a lot)

OK. I will try to disable deleting of /var/tmp/kdecache-`whoami` and will make a report after some days.

> Other options would be:
> - defect HDD sector (badblocks, fsck)
most likely not the case (about a year old SSD without noticing any problems in other areas. smartd reports no errors)

> - out of disk space (df -h)
definitely not

I have another crash. I have made screenshot just after the crash (attached in crash-snapshot2.png). I have also made dump of files in /var/tmp before the crash (after KDE start) and just after the crach (attached in ls.var-tmp.*.kwin.crash). By the comparison, it does not seem that anything was removed (anyway, I think that the /var/tmp/ authomatic cleaning is switched off off)

Here is the report:

Application: Run Command Interface (kdeinit4), signal: Aborted
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fdd9c74e780 (LWP 728))]

Thread 10 (Thread 0x7fdd814a8700 (LWP 776)):
#0  0x00007fdd99d9e2cd in poll () from /usr/lib/libc.so.6
#1  0x00007fdd96cf7744 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007fdd96cf7864 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007fdd9b3ce766 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#4  0x00007fdd9b39f33f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#5  0x00007fdd9b39f5c8 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6  0x00007fdd9b2a07c0 in QThread::exec() () from /usr/lib/libQtCore.so.4
#7  0x00007fdd9b37faff in ?? () from /usr/lib/libQtCore.so.4
#8  0x00007fdd9b2a379c in ?? () from /usr/lib/libQtCore.so.4
#9  0x00007fdd9b013e0f in start_thread () from /usr/lib/libpthread.so.0
#10 0x00007fdd99da645d in clone () from /usr/lib/libc.so.6

Thread 9 (Thread 0x7fdd72c55700 (LWP 1027)):
#0  0x00007fdd9b017954 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fdd9b2a3cfb in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4
#2  0x00007fdd8d266df1 in ?? () from /usr/lib/libthreadweaver.so.4
#3  0x00007fdd8d26963b in ?? () from /usr/lib/libthreadweaver.so.4
#4  0x00007fdd8d2684af in ?? () from /usr/lib/libthreadweaver.so.4
#5  0x00007fdd8d26853b in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4
#6  0x00007fdd9b2a379c in ?? () from /usr/lib/libQtCore.so.4
#7  0x00007fdd9b013e0f in start_thread () from /usr/lib/libpthread.so.0
#8  0x00007fdd99da645d in clone () from /usr/lib/libc.so.6

Thread 8 (Thread 0x7fdd72454700 (LWP 1028)):
#0  0x00007fdd9b017954 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fdd9b2a3cfb in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4
#2  0x00007fdd8d266df1 in ?? () from /usr/lib/libthreadweaver.so.4
#3  0x00007fdd8d26963b in ?? () from /usr/lib/libthreadweaver.so.4
#4  0x00007fdd8d269654 in ?? () from /usr/lib/libthreadweaver.so.4
#5  0x00007fdd8d2684af in ?? () from /usr/lib/libthreadweaver.so.4
#6  0x00007fdd8d26853b in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4
#7  0x00007fdd9b2a379c in ?? () from /usr/lib/libQtCore.so.4
#8  0x00007fdd9b013e0f in start_thread () from /usr/lib/libpthread.so.0
#9  0x00007fdd99da645d in clone () from /usr/lib/libc.so.6

Thread 7 (Thread 0x7fdd71c53700 (LWP 1029)):
#0  0x00007fdd9b017954 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fdd9b2a3cfb in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4
#2  0x00007fdd8d266df1 in ?? () from /usr/lib/libthreadweaver.so.4
#3  0x00007fdd8d26963b in ?? () from /usr/lib/libthreadweaver.so.4
#4  0x00007fdd8d269654 in ?? () from /usr/lib/libthreadweaver.so.4
#5  0x00007fdd8d2684af in ?? () from /usr/lib/libthreadweaver.so.4
#6  0x00007fdd8d26853b in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4
#7  0x00007fdd9b2a379c in ?? () from /usr/lib/libQtCore.so.4
#8  0x00007fdd9b013e0f in start_thread () from /usr/lib/libpthread.so.0
#9  0x00007fdd99da645d in clone () from /usr/lib/libc.so.6

Thread 6 (Thread 0x7fdd71452700 (LWP 1030)):
#0  0x00007fdd9b017954 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fdd9b2a3cfb in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4
#2  0x00007fdd8d266df1 in ?? () from /usr/lib/libthreadweaver.so.4
#3  0x00007fdd8d26963b in ?? () from /usr/lib/libthreadweaver.so.4
#4  0x00007fdd8d269654 in ?? () from /usr/lib/libthreadweaver.so.4
#5  0x00007fdd8d2684af in ?? () from /usr/lib/libthreadweaver.so.4
#6  0x00007fdd8d26853b in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4
#7  0x00007fdd9b2a379c in ?? () from /usr/lib/libQtCore.so.4
#8  0x00007fdd9b013e0f in start_thread () from /usr/lib/libpthread.so.0
#9  0x00007fdd99da645d in clone () from /usr/lib/libc.so.6

Thread 5 (Thread 0x7fdd70c51700 (LWP 1031)):
#0  0x00007fdd9b017954 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fdd9b2a3cfb in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4
#2  0x00007fdd8d266df1 in ?? () from /usr/lib/libthreadweaver.so.4
#3  0x00007fdd8d26963b in ?? () from /usr/lib/libthreadweaver.so.4
#4  0x00007fdd8d269654 in ?? () from /usr/lib/libthreadweaver.so.4
#5  0x00007fdd8d2684af in ?? () from /usr/lib/libthreadweaver.so.4
#6  0x00007fdd8d26853b in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4
#7  0x00007fdd9b2a379c in ?? () from /usr/lib/libQtCore.so.4
#8  0x00007fdd9b013e0f in start_thread () from /usr/lib/libpthread.so.0
#9  0x00007fdd99da645d in clone () from /usr/lib/libc.so.6

Thread 4 (Thread 0x7fdd6bfff700 (LWP 1032)):
#0  0x00007fdd9b017954 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fdd9b2a3cfb in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4
#2  0x00007fdd8d266df1 in ?? () from /usr/lib/libthreadweaver.so.4
#3  0x00007fdd8d26963b in ?? () from /usr/lib/libthreadweaver.so.4
#4  0x00007fdd8d269654 in ?? () from /usr/lib/libthreadweaver.so.4
#5  0x00007fdd8d2684af in ?? () from /usr/lib/libthreadweaver.so.4
#6  0x00007fdd8d26853b in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4
#7  0x00007fdd9b2a379c in ?? () from /usr/lib/libQtCore.so.4
#8  0x00007fdd9b013e0f in start_thread () from /usr/lib/libpthread.so.0
#9  0x00007fdd99da645d in clone () from /usr/lib/libc.so.6

Thread 3 (Thread 0x7fdd6b7fe700 (LWP 1033)):
#0  0x00007fdd9b017954 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fdd9b2a3cfb in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4
#2  0x00007fdd8d266df1 in ?? () from /usr/lib/libthreadweaver.so.4
#3  0x00007fdd8d26963b in ?? () from /usr/lib/libthreadweaver.so.4
#4  0x00007fdd8d269654 in ?? () from /usr/lib/libthreadweaver.so.4
#5  0x00007fdd8d2684af in ?? () from /usr/lib/libthreadweaver.so.4
#6  0x00007fdd8d26853b in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4
#7  0x00007fdd9b2a379c in ?? () from /usr/lib/libQtCore.so.4
#8  0x00007fdd9b013e0f in start_thread () from /usr/lib/libpthread.so.0
#9  0x00007fdd99da645d in clone () from /usr/lib/libc.so.6

Thread 2 (Thread 0x7fdd6affd700 (LWP 1034)):
#0  0x00007fdd9b017954 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fdd9b2a3cfb in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4
#2  0x00007fdd8d266df1 in ?? () from /usr/lib/libthreadweaver.so.4
#3  0x00007fdd8d26963b in ?? () from /usr/lib/libthreadweaver.so.4
#4  0x00007fdd8d2684af in ?? () from /usr/lib/libthreadweaver.so.4
#5  0x00007fdd8d26853b in ThreadWeaver::Thread::run() () from /usr/lib/libthreadweaver.so.4
#6  0x00007fdd9b2a379c in ?? () from /usr/lib/libQtCore.so.4
#7  0x00007fdd9b013e0f in start_thread () from /usr/lib/libpthread.so.0
#8  0x00007fdd99da645d in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7fdd9c74e780 (LWP 728)):
[KCrash Handler]
#5  0x00007fdd99cf4fa5 in raise () from /usr/lib/libc.so.6
#6  0x00007fdd99cf6428 in abort () from /usr/lib/libc.so.6
#7  0x00007fdd99d33cfb in __libc_message () from /usr/lib/libc.so.6
#8  0x00007fdd99dbbad7 in __fortify_fail () from /usr/lib/libc.so.6
#9  0x00007fdd99db9bb0 in __chk_fail () from /usr/lib/libc.so.6
#10 0x00007fdd99dbba47 in __fdelt_warn () from /usr/lib/libc.so.6
#11 0x00007fdd9b37b9a4 in ?? () from /usr/lib/libQtCore.so.4
#12 0x00007fdd87729c58 in ?? () from /usr/lib/libkdeinit4_krunner.so
#13 0x00007fdd9b3b5acf in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4
#14 0x00007fdd8772b252 in ?? () from /usr/lib/libkdeinit4_krunner.so
#15 0x00007fdd9b3b4ddc in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4
#16 0x00007fdd9a58307a in QWidget::event(QEvent*) () from /usr/lib/libQtGui.so.4
#17 0x00007fdd9a53408c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#18 0x00007fdd9a53850a in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#19 0x00007fdd9c141df6 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#20 0x00007fdd9b3a05ee in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4
#21 0x00007fdd9b3d0fb2 in ?? () from /usr/lib/libQtCore.so.4
#22 0x00007fdd9b3ce0e4 in ?? () from /usr/lib/libQtCore.so.4
#23 0x00007fdd9b3ce101 in ?? () from /usr/lib/libQtCore.so.4
#24 0x00007fdd96cf7475 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#25 0x00007fdd96cf77a8 in ?? () from /usr/lib/libglib-2.0.so.0
#26 0x00007fdd96cf7864 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#27 0x00007fdd9b3ce746 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#28 0x00007fdd9a5d450e in ?? () from /usr/lib/libQtGui.so.4
#29 0x00007fdd9b39f33f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#30 0x00007fdd9b39f5c8 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#31 0x00007fdd9b3a4268 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#32 0x00007fdd877123cf in kdemain () from /usr/lib/libkdeinit4_krunner.so
#33 0x0000000000408342 in _start ()

Created attachment 74972 [details]
The screenshot just after the crach

Created attachment 74973 [details]
content of /var/tmp/ after KDE start

Created attachment 74974 [details]
content of /var/tmp/ after the crash

That's a backtrace from a krunner abort.
The library is stripped, so it's not possible to say what actually caused this, but it's rather unlikely kshareddatacache and unlikely related (no mention of libplasma or libkdecore)

Regarding the file presence: *deleting* a file is completely harmless regarding kshareddatacache, the problem would be if the inodes under the file handle are overridden with "random data" (ie. anything not expected by the cache)

> That's a backtrace from a krunner abort.

well, that's the first crash window which appeared after the plasma disappear. So the bug is (most likely) not related to kwin ... Could you, please, change the title?

> The library is stripped, so it's not possible to say what actually caused this

Yes, unfortunately. See the first issue :-(

I have a "monitor" script which logs 'ps afx' and 'ls -R /var/tmp' every 2 minutes, so I could get rather up-to-date state before and after crash.

What next should I do?

re-assigning.
The bug is likely INVALID, but the KSharedData core team might have a better opinion on what's going wrong here (or idea how to figure that)

>I have a "monitor" script which logs 'ps afx' and 'ls -R /var/tmp' every 2 minutes

The data is likely pretty irrelevant, since the "ls -R" will only print what's there, not when it was modified or so - and even then: the shared data cache will be accessed soo often, that this information will likely be useless as well.

logging (as root)
   lsof | grep -E '/var/tmp/kdecache-dan/.*kcache'
presuming your account is "dan", could catch the relevant piece

The first thing i'd however try would be to disable all "monitor" and other (custom) scripts accessing /var/tmp and see whether the issue remains.

Btw, when you say it happens all "two or three days", do you mean "uptime" or "occasionally" (ie. can you eg. prevent it by logging out and in once a day or so? - no. no solution, but hint ;-)

OK, I have stopped the logging and will see. If it will crash (I am pretty sure that it will), I will start the lsof "logger"

> Btw, when you say it happens all "two or three days", do you mean "uptime" or "occasionally" (ie. can you eg. prevent it by logging out and in once a day or so? - no. no solution, but hint ;-)

Well, it is after few "evenings" of use, while the computer was suspended to ram during the day.

It took little but longer now, but the crash appeared finally.

Looking at the output of 'ps afx' before and after the crash, the following processes are gone:

   676 ?        Sl    19:28 kdeinit4: plasma-desktop [kdeinit]             
   679 ?        S      1:10  \_ ksysguardd

and also those, but I don't think that they are a cause of the crash:

16068 ?        S      0:00  \_ kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-dtihelka/
16070 ?        S      0:00  \_ kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-dtihelka/
16072 ?        S      0:00  \_ kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-dtihelka/
16077 ?        S      0:00  \_ kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-dtihelka/

I have started the 'lsof' as you suggested, and I will also try KDE 4.9.3.

The original backtrace (where plasma-desktop crashed on a Bus error signal) is likely a KSharedDataCache bug assuming there were no other programs writing to the /var/tmp/kdecache-$USER/*.kcache files. I thought I had improved crash safety for SIGBUS by KDE 4.9.2 but apparently that's not the case here.

if your distribution has debugging symbols available for kdelibs that would greatly help with debugging. What I really need is something like Valgrind but only for mmap'ed memory accesses... I wonder if there's a debugging tool like that.

Hello,
I have switched to 4.9.3 and the issue still remains. However, I have found that it may be somehow connected with konqueror, since the desktop crashes when I browse net.

I will try some pages to know. if it can be repeated

Dan

Well, I didn't found anything useful. Just now the plasma crashed again, and I have opened only the following pages in konqueror:

http://sourceforge.net/apps/mediawiki/irstlm/index.php?title=Main_Page
https://webmail.zcu.cz/SOGo/so/dtihelka/Mail/view

The plasma crashed at the momed I have switched from the first opened page to the second opened page, after 3 evenings of using the computer (uptime: 23:21:59 up 1 day,  1:50,  2 users,  load average: 0.16, 0.10, 0.16), with 2 syspends to ram in between. I did not do anything else !!??

Except the konqueror, I have running the following processes (ps -afx after the crash):

    1 ?        Ss     0:00 /sbin/init
  134 ?        Ss     0:00 /usr/lib/systemd/systemd-udevd
  170 ?        Ss     0:01 /usr/lib/systemd/systemd-journald
  395 ?        Ssl    0:00 /usr/sbin/NetworkManager --no-daemon
 7985 ?        S      0:00  \_ /usr/sbin/dhclient -d -4 -sf /usr/lib/networkmanager/nm-dhcp-client.action -pf /var/run/dhclient-eth0.pid -lf /var/lib/dhclient/
  407 ?        Ss     0:00 /usr/lib/systemd/systemd-logind
  415 ?        Ss     0:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
  425 ?        Ssl    0:01 /usr/lib/polkit-1/polkitd --no-debug
  430 tty1     Ss+    0:00 /sbin/agetty --noclear tty1 38400
  431 ?        Ss     0:00 /usr/bin/kdm -nodaemon
  438 tty7     Ss+    3:59  \_ /usr/bin/X :0 vt7 -nolisten tcp -auth /var/run/xauth/A:0-pKw6Za
  460 ?        S      0:00  \_ -:0                   
  483 ?        Ss     0:00      \_ /bin/sh /usr/bin/startkde
  591 ?        S      0:00          \_ kwrapper4 ksmserver
  482 ?        Ss     0:39 encfs -S /scr/dtihelka/ /home/dtihelka -- -o nonempty
  494 ?        S      0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session
  495 ?        Ss     0:03 /usr/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
  500 ?        Sl     1:41 /usr/bin/pulseaudio --start
  508 ?        S      0:00  \_ /usr/lib/pulse/gconf-helper
  501 ?        SNsl   0:00 /usr/lib/rtkit/rtkit-daemon
  510 ?        S      0:00 /usr/lib/GConf/gconfd-2
  538 ?        Ss     0:00 /usr/bin/ssh-agent -s
  552 ?        S      0:00 /usr/lib/kde4/libexec/start_kdeinit +kcminit_startup
  553 ?        Ss     0:00 kdeinit4: kdeinit4 Running...                  
  554 ?        S      0:00  \_ kdeinit4: klauncher [kdeinit] --fd=9           
  592 ?        Sl     0:00  \_ kdeinit4: ksmserver [kdeinit]                  
  684 ?        Sl     2:39  |   \_ kwin
  757 ?        Sl     0:00  \_ kdeinit4: nepomukserver [kdeinit]              
  761 ?        SNl    0:13  |   \_ /usr/bin/nepomukservicestub nepomukstorage
  809 ?        SNl    0:51  |   |   \_ /usr/bin/virtuoso-t +foreground +configfile /tmp/virtuoso_LhX761.ini +wait
  899 ?        SNl    0:09  |   \_ /usr/bin/nepomukservicestub nepomukfilewatch
  900 ?        SNl    0:00  |   \_ /usr/bin/nepomukservicestub nepomukfileindexer
  901 ?        SN     0:00  |   \_ /usr/bin/nepomukservicestub nepomukqueryservice
  902 ?        SN     0:00  |   \_ /usr/bin/nepomukservicestub nepomukbackupsync
  758 ?        S      0:00  \_ /usr/bin/kwrited
  772 ?        S      0:00  \_ python2 /usr/bin/printer-applet
 1010 ?        Sl    47:12  \_ kdeinit4: konqueror [kdeinit]                  
 4802 ?        S      0:07  |   \_ /usr/bin/nspluginviewer -dbusservice org.kde.nspluginviewer-1010
 1020 ?        S      0:00  \_ kdeinit4: kio_http_cache_cleaner [kdeinit]     
 8997 ?        Sl     0:00  \_ kdeinit4: kio_http [kdeinit] https local:/tmp/ksocket-dtihelka
 9003 ?        Sl     0:00  \_ kdeinit4: kio_http [kdeinit] https local:/tmp/ksocket-dtihelka
  556 ?        Sl     0:06 kdeinit4: kded4 [kdeinit]                      
  563 ?        S      0:00 kdeinit4: kglobalaccel [kdeinit]               
  567 ?        S      0:00 kdeinit4: kwalletd [kdeinit]                   
  571 ?        S      0:00 /usr/bin/kactivitymanagerd
  572 ?        Ssl    0:01 /usr/lib/upower/upowerd
  601 ?        Ssl    0:00 /usr/sbin/console-kit-daemon --no-daemon
  682 ?        Ssl    0:00 /usr/lib/udisks/udisks-daemon
  685 ?        S      0:00  \_ udisks-daemon: not polling any devices
  715 ?        Sl     0:01 /usr/bin/knotify4
  727 ?        S      0:00 /usr/bin/kuiserver
  733 ?        Sl     0:05 /usr/bin/mysqld --defaults-file=/home/dtihelka/.local/share/akonadi/mysql.conf --datadir=/home/dtihelka/.local/share/akonadi/db_data
  763 ?        Sl     0:04 kdeinit4: krunner [kdeinit]                    
  764 ?        Sl     0:20 /usr/bin/kopete -caption Kopete
  774 ?        Sl     0:00 /usr/lib/kde4/libexec/polkit-kde-authentication-agent-1
  785 ?        S      0:00 /usr/bin/korgac --icon korgac
  787 ?        Sl     0:00 kdeinit4: kmix [kdeinit]                       
  791 ?        S      0:00 kdeinit4: klipper [kdeinit]                    
  794 ?        S      0:00 /usr/bin/nepomukcontroller
  813 ?        Ssl    0:00 /usr/lib/colord/colord
  934 ?        Sl     2:32 kdeinit4: konsole [kdeinit]                    
  936 pts/1    Ss+    0:00  \_ /bin/bash
  984 pts/2    Ss+    0:00  \_ /bin/bash
  990 pts/3    Ss+    0:00  \_ /bin/bash
  996 pts/4    Ss     0:00  \_ /bin/bash
 1056 pts/4    S+     0:03  |   \_ mc
 1058 pts/6    Ss     0:00  |       \_ bash -rcfile .bashrc
 9024 pts/6    R+     0:00  |           \_ ps afx
 7551 pts/7    Ss     0:00  \_ /bin/bash
 8250 pts/7    S      0:00  |   \_ su -
 8251 pts/7    S      0:00  |       \_ -bash
 8356 pts/7    S+     0:00  |           \_ mc
 8358 pts/9    Ss+    0:00  |               \_ bash -rcfile .bashrc
 7683 pts/8    Ss     0:00  \_ /bin/bash
 8157 pts/8    S      0:00      \_ su -
 8158 pts/8    S      0:00          \_ -bash
 8166 pts/8    S+     0:02              \_ mc
 8168 pts/5    Ss+    0:00                  \_ bash -rcfile .bashrc
 8310 ?        Ss     0:00 /usr/sbin/cupsd -f

So, nothing special, really, is running ...

Created attachment 75538 [details]
Actual crash report

Created attachment 75539 [details]
lsof | grep -E '/var/tmp/kdecache-dtihelka/.*kcache' before crash

Created attachment 75540 [details]
lsof | grep -E '/var/tmp/kdecache-dtihelka/.*kcache' short after crash

this is not your only /var related crash issue, because bug #310381 is related through "InnoDB: Unable to lock ./ibdata1, error: 11" as well, so together, it seems sth. causes serious harm to that path.

Either it's some "weird" mount parameters (is /var an extra mout) or sth. scrubs across it and leaves an inode mess behind.

-> Have you deactivated your /var cleaning scripts and can they seen somewhere?
Do they run during the session or on boot and if not, what happens if you ensure the latter?

> this is not your only /var related crash issue, because bug #310381 is related through "InnoDB: Unable to lock ./ibdata1, error: 11" as well, so together, it seems sth. causes serious harm to that path.

This started to happen with 4.9.3 after computer restart after crash

> Either it's some "weird" mount parameters (is /var an extra mout) or sth. scrubs across it and leaves an inode mess behind.

Here is how /var/tmp and my home is mount:
tmpfs on /var/tmp type tmpfs (rw,noatime,size=51200k)
encfs on /home/dtihelka type fuse.encfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=100,default_permissions)

The /var/ itself is "normal" directory. Is it the information what you require?

> -> Have you deactivated your /var cleaning scripts and can they seen somewhere?
> Do they run during the session or on boot and if not, what happens if you ensure the latter?

I have checked it again and ensured (now I am almost 100% sure) that they will run neither during boot, nor during session.

I forgot to note (but it could be visible from 'ps' and 'mount' lists), that my /home directory is encrypted using encfs. Anyway, bug #310381 did not happen with 4.9.2.

> tmpfs on /var/tmp type tmpfs (rw,noatime,size=51200k)
That are 50 (fifty!!) MB, while my kdecache is 761MB (ok, containing several plasma theme caches i tried)
Removing most of them and having one wallpaper, knights, kio, favicons, icons, http,  in the cache, it's stll 276MB and _every_ plasma theme takes up ~80MB anyway (after first invocation)

Long story short: do you mind trying to move /var/tmp to somewhere with a little more space? ;-)

Great! Thank you to point it out. Really, when the plasma crashed, the /var/tmp is full. I tried to increase the space and will see.

Thank you very much!

Still, I don't think that crash is an "understable" disk full message :-)

I don't know the cache implementation, but would it be possible to release some "old" content when storage where cache is located is starting to be full?

Michael will have to answer this but is suspect it won't be trivial.

"release because full" means "inodes will get overridden soon" and the memory is mapped into processes.

To know whether a file is currently in use you'll require strict contract (a persistent! dameon and processes telling the deamon about their holds on the memory) or root permissions (and time to look up the handles and probably linux)

If you want to keep the cache in some tmpfs I suggest once more to use some cramfs variant - plasma themes take by far most of the space and they contain virtually nothing but paddings and zeros and will be less than 1 MB in compressed state.

It would unfortunately be very trivial to resize an in-use cache at runtime.

Even if I could perfectly code the defragment and migration steps while taking into account the different page table, index table sizes, we would need a way to inform the processes that have the file mapped of the new size, and ensure that they re-map memory.

That's actually doable without having to send a specific IPC message (by storing the change as a flag in the shared cache itself and forcing all KSharedDataCache accesses to verify this flag). However this complicates it even more, and unfortunately I'm *not* sure that it's even possible to safely truncate the file until *all* open memory-mappings have been dropped (this is the part that's impossible without a persistent daemon of some sort tracking this).

You would think that it would be safe as long as no application accesses memory in the truncated region, but I've seen SIGBUS crash reports for many very minor reasons so I'm not willing to risk that.

Fair enough. Thanks for the explanation.
Dan

Probably for fixable in a simple way (see the comments).
The only solution is to make enough space for the cache :-)