Bug 259347

Nothing in KDE is secured against "out of resources" issues, this crash occured on opening an icon - what happens in every GUI application, all over the time.
I also doubt that kconfig is somehow checking resources.

The situation gets worse:
if not only your $HOME path is affected (mount/quota) but the disk is really full, you'll get crashes all over the place and there's a good chance that at some point the kernel will halt.

So ultimately this would be a general kdelibs issue, but i assmue it "won't fix", sorry.

*** Bug 259346 has been marked as a duplicate of this bug. ***

Thomas, there is no reason a program should crash when the disk is full. Especially when the disk is just used as a cache.

No, it _should_ not, and in a perfect world it _would_ not.
Stupid thing is that reality is getting in your way:

"gg:linux shm bus error mmap" :-(

i didn't mean to imply "KDE code should require infinite resources" and actually kshareddatacache appears to properly prevent allocation of invalid shm accesses, but it's just that many applications/libraries will stumble on this.

Long story short: rather don't run out of disk space ;-)

Indeed, I am pretty sure I have done all that is feasible:

* The file that backs the cache is resized only once, the first time it is used, and that resize must succeed to proceed further.
* If a new cache is being created, and the resize doesn't succeed, KSDC immediately falls back to an anonymous memory mapping, which shouldn't involve disk access at all.
* Once the file-to-memory mapping succeeds, it is very difficult to reliably tell in all situations that an upcoming valid shared memory access will actually cause a crash, at least to my knowledge. I have "The Linux Programming Interface" on my wishlist so maybe I will find a suitable solution. I am, as always, willing to be clued into better ways to do it. Should there be a good way to do this I'm very willing to add it so that KSDC can simply return appropriate null values (it is, after all, just a cache, apps should expect data to disappear at random already).

Short story is that I'm not sure why resizing the file should succeed if the disk is full, or close to full, or why existing space allocated to a .kcache file should somehow be reassigned elsewhere. Is this possibly a "sparse file" problem? Is there a way to disable that, if that's the case?

a copy-on-write file system like btrfs needs space for overwriting existing files.

catching this situation in correlation with mmaps is indeed somewhat nasty.
i wonder whether it would be feasible to use the mmaps only for read access, while writing would be conventional file handle writes.

*** Bug 259635 has been marked as a duplicate of this bug. ***

That would likely handle the case of crash-on-update just fine. One issue is that strictly speaking a simple fetch updates the use count and "last accessed" portions of the applicable index entry. But, it's probably possible to batch those updates together so that file access can be used for those as well.

One other way to go is add a way for non-file-backed caching (and make it default). I think this is supported on both POSIX shm and Linux (with "anonymous files")

grepping kshareddatacache & qt/corelib/io/* - and regarding the little discussion there was about ext3... i wonder if this could just lack an fsync? (after Qfile::open())

*** This bug has been marked as a duplicate of bug 245173 ***