https://bugs.kde.org/show_bug.cgi?id=423928
Bug ID: 423928
Summary: kdirwatch refcounting (stop exhausting
fs.inotify.max_user_instances)
Product: frameworks-kcoreaddons
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: mp...@kde.org
Reporter: sit...@kde.org
CC: kdelibs-b...@kde.org
Target Milestone: ---
If I'm reading the code correctly kdirwatch shares its private instances and
puts them into thread-local storage. This really ought to have refcounting in
place so the private instance is thrown away when all "fronting" objects have
been deleted. Otherwise threads that create temporary KDirWatch objects will
create inotify instances that ultimately end up being unused 99% of the time
but still counting against the per-user cap on instances. This can somewhat
easily exhaust the instance cap.
For example see comment 4 on bug #423818 which I suspect may be at least
partially caused by kdirwatch. plasmashell and krunner have a decent amount of
instances (entries in the table) but almost all have no active watches (first
column) because they are inactive.
Some gdb breaking suggests this is caused by the krunner framework which runs
runner processes in threadweaver managed threads. These runners may use
KService and thus cause a temporary KDirWatch on the ksycoca database. Since
the thread assignment out of the thread pool is random the runner will
eventually have run on all possible threads and consequently left behind unused
kdirwatchprivate instances on all of them.
KDirWatchPrivate should have refcounting. Once all its associated KDirWatch
objects are gone the Private object should delete itself as well (maybe with a
second or so delay just in case an application is being silly?).
--
You are receiving this mail because:
You are watching all bug changes.
