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

Nicolas Fella <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Latest Commit|https://invent.kde.org/fram |https://invent.kde.org/fram
                   |eworks/kservice/-/commit/2d |eworks/kservice/-/commit/3e
                   |e8b433550f5614778394f441f66 |c3e084db1005b34fd1debd73346
                   |35769c9613f                 |ef6c79fe6da

--- Comment #16 from Nicolas Fella <[email protected]> ---
Git commit 3ec3e084db1005b34fd1debd73346ef6c79fe6da by Nicolas Fella, on behalf
of Harald Sitter.
Committed on 02/03/2026 at 15:17.
Pushed by nicolasfella into branch 'Frameworks/6.23'.

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!
(cherry picked from commit 2de8b433550f5614778394f441f6635769c9613f)

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/3ec3e084db1005b34fd1debd73346ef6c79fe6da

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

Reply via email to