https://bugs.kde.org/show_bug.cgi?id=520794
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #10 from [email protected] --- Hi everyone, I encountered this crash recently and looked into the coredump and source code locally. I would like to share what I found in case it might be helpful as a clue (please feel free to correct me if I misunderstood anything). Looking at src/kioworkers/trash/trashimpl.cpp in TrashImpl::adaptTrashSize: const auto dirCache = cache.readDirCache(); constexpr QDir::Filters dirFilters = QDir::Files | QDir::AllDirs | QDir::NoDotAndDotDot; const QFileInfoList infoList = QDir(trashPath + QLatin1String("/files")).entryInfoList(dirFilters, sortFlags); for (const auto &info : infoList) { auto fileSizeFreed = info.size(); if (info.isDir()) { fileSizeFreed = dirCache.constFind(info.path().toUtf8())->size; } ... It seems there might be two potential issues when the oldest item being removed is a directory: 1. Key lookup: info.path() returns the containing directory path (trashPath + "/files"), rather than the item's own name (info.fileName()). In addition, readDirCache() seems to populate keys using percent-encoded names (QFile::encodeName(...).toPercentEncoding()), so the lookup might not be finding the key. 2. Missing iterator check: dirCache.constFind(...) is dereferenced directly (->size) without checking whether it equals dirCache.constEnd(). If the entry is not found in the cache, dereferencing the end iterator appears to cause an immediate SIGSEGV. This might also explain why the crash was difficult to reproduce with single large files: When the oldest item in the trash is a regular file, info.isDir() evaluates to false, taking fileSizeFreed = info.size() safely. The crash only seems to happen when the oldest item to be deleted happens to be a directory / folder. -- You are receiving this mail because: You are watching all bug changes.
