https://bugs.kde.org/show_bug.cgi?id=467888
Harald Sitter <sit...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|REPORTED |RESOLVED
Latest Commit| |https://invent.kde.org/plas
| |ma/discover/-/commit/2e52e7
| |c9aa44ca1b3f5009fd7e6daf66f
| |c8d31a6
--- Comment #9 from Harald Sitter <sit...@kde.org> ---
Git commit 2e52e7c9aa44ca1b3f5009fd7e6daf66fc8d31a6 by Harald Sitter.
Committed on 06/10/2023 at 13:14.
Pushed by sitter into branch 'master'.
packagekit: hold stream in a qpointer
there is a very awkward race condition involving streams during
initialization. if any of the (KNS) backends fail to initialize and
become invalid they will eventually trigger
`ResourcesModel::callerFetchingChanged` which will discard the now
invalid backends and emit `backendsChanged` which will trigger
`ResourcesProxyModel::invalidateFilter` which then may end up deleting
the current stream
```
if (m_currentStream) {
qCWarning(LIBDISCOVER_LOG) << "last stream isn't over yet" <<
m_filters << this;
delete m_currentStream;
```
this is in so far problematic as we "schedule" lambda executions in the
packagekit backend (most prominently in `PackageKitBackend::search`)
with lambdas that hold the stream. these lambdas will eventually run on
since-deleted stream objects and best case fall into a nullptr but more
regularly just fall into a ditch of random memory until undefined
behavior bites us
Related: bug 465711, bug 473921
M +31 -8 libdiscover/backends/PackageKitBackend/PackageKitBackend.cpp
https://invent.kde.org/plasma/discover/-/commit/2e52e7c9aa44ca1b3f5009fd7e6daf66fc8d31a6
--
You are receiving this mail because:
You are watching all bug changes.
