[Bug 160284] bad mmap causes cores in KPCMemoryDevice

[Michael Pyne]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=160284         




------- Additional Comments From mpyne purinchu net  2008-06-06 22:17 -------
Sebastian, I think that strictly speaking that remaining bugs in KPixmapCache are not related to this one anyways.

As far as where to go from here, I would say we need to have a reliable mechanism to force all KPixmapCaches in all processes to unmap shared memory if the size of the underlying file will be changed since we don't handle this case yet.  I think a QWaitCondition fits the bill but I need to figure out how to make this transparent to the application (or maybe Qt 4 has already made this easy, I haven't dealt much with threads)

The cache resize exposed to public API through KPixmapCache::setCacheLimt() so we do need to fix it at some point.  We could then use the same mechanism for when the cache is supposed to be deleted.  The mmap(2) man page says it opens another reference to the fd so I take that to mean that the inode itself is safe if the file is unlinked.

I think I will open a separate bug to deal with the KPixmapCache::setCacheLimit() issue so let's leave this one alone unless we start getting SIGBUS'es due to KPixmapCache again.