https://bugs.kde.org/show_bug.cgi?id=516426

Harald Sitter <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
      Latest Commit|                            |https://invent.kde.org/fram
                   |                            |eworks/kservice/-/commit/2d
                   |                            |e8b433550f5614778394f441f66
                   |                            |35769c9613f

--- Comment #15 from Harald Sitter <[email protected]> ---
Git commit 2de8b433550f5614778394f441f6635769c9613f by Harald Sitter.
Committed on 02/03/2026 at 07:25.
Pushed by sitter into branch 'master'.

ksycoca: do not allow for recursive repairs

this is a mighty complicated issue.

fiddling with kservice/ksycoca will trigger creation of KSycoca and
KServiceFactory instances. eventually the call chains arrive in
KSycocaFactory and move on to findFactory. findFactory performs a
checkDatabase and that may auto-repair the database if it finds it to be
out of date or broken. this then closes and reopens the database (a
singleton by virtue of KSycoca being a singleton) and eventually issues
databaseChanged.

at this point an observant user may react to the database change and
adopt the changes... by calling into kservice/ksycoca. A fatal problem.

this produces a recursive call chain where we perform the entire
factorization dance again. If now, and this is the tricky bit, anything
caused another rebuild to be needed (e.g. a desktop file changing) then
the database will get closed and opened again and now the outer call
chain has a thrashed state (both call chains worked on the same
singleton, mind, so closing it in the inner chain breaks the outter
chain).

a specific scenario of this is happening in plasma-nm where QRCA tech
reacts to database changes with a service lookup, producing another
database change, thrashing the state, and eventually cashing.

to deal with this we simply emit database changes in a queued fashion.

we really really really should simplify this framework!

M  +32   -1    autotests/kservicetest.cpp
M  +2    -1    autotests/kservicetest.h
M  +13   -0    src/services/kservicefactory.cpp
M  +12   -2    src/sycoca/ksycoca.cpp

https://invent.kde.org/frameworks/kservice/-/commit/2de8b433550f5614778394f441f6635769c9613f

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to