Summary: | muon crashes while browsing | ||
---|---|---|---|
Product: | [Applications] Discover | Reporter: | charlie <charlie.reddington> |
Component: | discover | Assignee: | Jonathan Thomas <echidnaman> |
Status: | RESOLVED WORKSFORME | ||
Severity: | crash | CC: | aaronn43, aleixpol, meriutacornel, sitter |
Priority: | NOR | Keywords: | drkonqi, triaged |
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | New crash information added by DrKonqi |
Description
charlie
2013-11-10 12:28:30 UTC
Created attachment 84387 [details]
New crash information added by DrKonqi
muon-discover (2.1.1) on KDE Platform 4.11.3 using Qt 4.8.4
- What I was doing when the application crashed: I was browaing for movie player when muon discovery crashed.
-- Backtrace (Reduced):
#7 0xa735aa02 in FindPkg (this=0x0, Name=...) at /usr/include/apt-pkg/depcache.h:348
#8 QApt::Backend::package (this=this@entry=0xa7e2640, name=...) at /build/buildd/qapt-2.0.65/src/backend.cpp:341
#9 0xa735aafe in QApt::Backend::package (this=0xa7e2640, name=...) at /build/buildd/qapt-2.0.65/src/backend.cpp:334
#10 0xa5c20d26 in Application::package (this=this@entry=0xa2f7a600) at /build/buildd/muon-2.1.1/libmuon/backends/ApplicationBackend/Application.cpp:137
#11 0xa5c2101c in Application::state (this=0xa2f7a600) at /build/buildd/muon-2.1.1/libmuon/backends/ApplicationBackend/Application.cpp:485
Explodes because: backend.cpp: > pkgCache::PkgIterator pkg = d->cache->depCache()->FindPkg(name.latin1()); cache.cpp: > pkgDepCache *Cache::depCache() const > { > Q_D(const Cache); > return *d->cache; cache is a pkgCacheFile operator* accesses it's member DCache; DCache is only initalized after pkgCacheFile::Open was called; as done in QApt::Cache::open; as called by Backend::reloadCache; forcibly called by Backend::init (which may return false!). So the obvious cause is that the Backend object is not initialized, hence the nullptr access. So the issue ultimately resides somewhere in ApplicationBackend.cpp; Backend::init is called via Qtimer(10)->::initBackend()->QtConcurrent::run so this crash most likely is a threading problem with the backend not being initalized in time and/or being used before becoming initalized (I hardly understand that beast TBH). I am reasonable certain that bug #325109 also plays into the same problem. Culprit is that backend.cpp does for loop iteration over its PackageList member at various points > (int i = 0; i < d->packages.size(); ++i) which in turn of course explodes with threading because Backend::reloadCache will rebuild the PackageList member thus changing size() etc. So perhaps the solution here is to a) make backend.cpp threadsafe or b) not thread it. Randomly guessing however I'd say that the reason it is threaded is because reloadCache/init takes too long, which looking at backend.cpp should be fixable by internally doing partial lazy inits. For example Backend::package(QLatin1String name) only needs d->cache so it should only init/open the cache. Backend::package(pkgCache::PkgIterator &iter) needs d->packagesIndex and d->packages, so those two should be lazy init'd here. etc. etc. Whether that is better than making the class thread-safe or not is another question, but general speaking I am assuming none of qapt is explicitly thread-safe so using it in a threaded environment at all sounds like a really bad idea. *** Bug 330477 has been marked as a duplicate of this bug. *** I'm pretty sure this was fixed at some point in libqapt. Otherwise, please ask your distributor to adopt the PackageKit backend. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |