https://bugs.kde.org/show_bug.cgi?id=469445
Nate Graham <n...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version Fixed In|5.27.9 |
Resolution|FIXED |---
Ever confirmed|1 |0
Summary|Ever-growing ScreenMapping |ScreenMapping entry in
|entry in config file makes |config file can grow
|plasmashell slow down and |infinitely due to lack of
|eventually crash |auto-removal of stale
| |entries, which makes
| |plasmashell slow down and
| |eventually crash
Priority|VHI |HI
Status|RESOLVED |REPORTED
--- Comment #43 from Nate Graham <n...@kde.org> ---
(In reply to pallaswept from comment #39)
> So, to fix this, you have two ways that can work:
> 1) Find every possible way out of an undefined number of possible ways, to
> remove a file, and have it left in the list, and fix every one of them (ie
> hey, pallaswept, I can't reproduce it, so you reproduce it, N times for the
> N variations that cause this (N being an undefined number that could be
> infinite for all we know), and log a new case N times)
>
> OR
>
> Just check that the entries in the list actually exist and remove them if
> they don't.
That's the crux of it.
The issue with option #1 is that we'll be playing whack-a-mole forever, and
it's not even theoretically fixable for the case you provided where you log
into a non-Plasma desktop, delete some files, and lot into Plasma again.
This leaves option #2, which is pretty easy but the problem is that checking
for the existence of all those files requires a bunch of stat calls. If for
example we did them at plasmashell startup in a blocking fashion, it would slow
down plasmashell's startup or make it hang if you've done something silly like
put a symlink on the desktop that points to a file on an unmounted NFS share
(yes, people do crazy things like this).
Maybe it would work if we made the stat calls non-blocking and did them in the
background in a different thread, rather than all at once on startup, it would
be fine.
Rer-opening and lowering priority, since it's now been partially fixed enough
to make this not be a pants-on-fire level issue.
--
You are receiving this mail because:
You are watching all bug changes.
