Bug 327406

Summary: muon crashes while browsing
Product: [Applications] Discover Reporter: charlie <charlie.reddington>
Component: discoverAssignee: 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
Application: muon-discover (2.1.0)
KDE Platform Version: 4.11.2
Qt Version: 4.8.4
Operating System: Linux 3.11.0-12-generic x86_64
Distribution: Ubuntu 13.10

-- Information about the crash:
- What I was doing when the application crashed:

Right after the kubuntu install, I was going through and installing some other software. I just did a software update, and I was installing firefox and it crashed. I re-opened it, and was install keepassx, and it crashed again. 

I was able to get updates done and software installed after trying again.

The crash can be reproduced sometimes.

-- Backtrace:
Application: Muon Discover (muon-discover), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fdbca2517c0 (LWP 31417))]

Thread 5 (Thread 0x7fdbaf8cb700 (LWP 31418)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007fdbc3a3706b in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#2  0x00007fdbc3a370a9 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#3  0x00007fdbbfbfaf6e in start_thread (arg=0x7fdbaf8cb700) at pthread_create.c:311
#4  0x00007fdbc6f1c9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 4 (Thread 0x7fdb2e5d0700 (LWP 31419)):
#0  0x00007fdbbf7620f2 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x00007fdbbf7623c9 in g_mutex_unlock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fdbbf722299 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fdbbf722708 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007fdbbf7227ac in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007fdbc7695a76 in QEventDispatcherGlib::processEvents (this=0x7fdb280008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:426
#6  0x00007fdbc76675ef in QEventLoop::processEvents (this=this@entry=0x7fdb2e5cfd70, flags=...) at kernel/qeventloop.cpp:149
#7  0x00007fdbc76678e5 in QEventLoop::exec (this=this@entry=0x7fdb2e5cfd70, flags=...) at kernel/qeventloop.cpp:204
#8  0x00007fdbc756688f in QThread::exec (this=this@entry=0x1525850) at thread/qthread.cpp:542
#9  0x00007fdbc7648d13 in QInotifyFileSystemWatcherEngine::run (this=0x1525850) at io/qfilesystemwatcher_inotify.cpp:265
#10 0x00007fdbc7568f2f in QThreadPrivate::start (arg=0x1525850) at thread/qthread_unix.cpp:338
#11 0x00007fdbbfbfaf6e in start_thread (arg=0x7fdb2e5d0700) at pthread_create.c:311
#12 0x00007fdbc6f1c9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 3 (Thread 0x7fdb2cec1700 (LWP 31420)):
#0  0x00007fdbbfbfd055 in __GI___pthread_mutex_lock (mutex=0x7fdb1c000a60) at pthread_mutex_lock.c:95
#1  0x00007fdbbf7623a1 in g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fdbbf721d59 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fdbbf7225c3 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007fdbbf7227ac in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007fdbc7695a76 in QEventDispatcherGlib::processEvents (this=0x7fdb1c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:426
#6  0x00007fdbc76675ef in QEventLoop::processEvents (this=this@entry=0x7fdb2cec0db0, flags=...) at kernel/qeventloop.cpp:149
#7  0x00007fdbc76678e5 in QEventLoop::exec (this=this@entry=0x7fdb2cec0db0, flags=...) at kernel/qeventloop.cpp:204
#8  0x00007fdbc756688f in QThread::exec (this=<optimized out>) at thread/qthread.cpp:542
#9  0x00007fdbc7568f2f in QThreadPrivate::start (arg=0x152f5b0) at thread/qthread_unix.cpp:338
#10 0x00007fdbbfbfaf6e in start_thread (arg=0x7fdb2cec1700) at pthread_create.c:311
#11 0x00007fdbc6f1c9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 2 (Thread 0x7fdb2294c700 (LWP 31421)):
#0  0x00007fdbbfbfe05f in __pthread_mutex_unlock_usercnt (mutex=0x7fdb14000a60, decr=<optimized out>) at pthread_mutex_unlock.c:52
#1  0x00007fdbbf7623d1 in g_mutex_unlock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fdbbf721d40 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007fdbbf7225c3 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007fdbbf7227ac in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007fdbc7695a76 in QEventDispatcherGlib::processEvents (this=0x7fdb140008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:426
#6  0x00007fdbc76675ef in QEventLoop::processEvents (this=this@entry=0x7fdb2294bdb0, flags=...) at kernel/qeventloop.cpp:149
#7  0x00007fdbc76678e5 in QEventLoop::exec (this=this@entry=0x7fdb2294bdb0, flags=...) at kernel/qeventloop.cpp:204
#8  0x00007fdbc756688f in QThread::exec (this=<optimized out>) at thread/qthread.cpp:542
#9  0x00007fdbc7568f2f in QThreadPrivate::start (arg=0x1851200) at thread/qthread_unix.cpp:338
#10 0x00007fdbbfbfaf6e in start_thread (arg=0x7fdb2294c700) at pthread_create.c:311
#11 0x00007fdbc6f1c9cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 1 (Thread 0x7fdbca2517c0 (LWP 31417)):
[KCrash Handler]
#6  0x00007fdb210eb14f in FindPkg (this=0x0, Name=...) at /usr/include/apt-pkg/depcache.h:348
#7  QApt::Backend::package (this=this@entry=0x1f6e6a0, name=...) at /build/buildd/qapt-2.0.65/src/backend.cpp:341
#8  0x00007fdb210eb227 in QApt::Backend::package (this=0x1f6e6a0, name=...) at /build/buildd/qapt-2.0.65/src/backend.cpp:334
#9  0x00007fdb13013aaf in Application::package (this=this@entry=0x7fdb00216490) at /build/buildd/muon-2.1.0/libmuon/backends/ApplicationBackend/Application.cpp:137
#10 0x00007fdb1300fa32 in ApplicationBackend::searchPackageName (this=<optimized out>, searchText=...) at /build/buildd/muon-2.1.0/libmuon/backends/ApplicationBackend/ApplicationBackend.cpp:499
#11 0x00007fdbc9e5ddee in ResourcesProxyModel::setSearch (this=this@entry=0x362d840, searchText=...) at /build/buildd/muon-2.1.0/libmuon/resources/ResourcesProxyModel.cpp:70
#12 0x00007fdbc9e4fd76 in ResourcesProxyModel::qt_metacall (this=this@entry=0x362d840, _c=_c@entry=QMetaObject::WriteProperty, _id=8, _a=_a@entry=0x7fffc7ff9a30) at /build/buildd/muon-2.1.0/obj-x86_64-linux-gnu/libmuon/moc_ResourcesProxyModel.cpp:165
#13 0x00007fdb2d65c027 in ApplicationProxyModelHelper::qt_metacall (this=0x362d840, _c=QMetaObject::WriteProperty, _id=<optimized out>, _a=0x7fffc7ff9a30) at /build/buildd/muon-2.1.0/obj-x86_64-linux-gnu/libmuon/declarative/moc_ApplicationProxyModelHelper.cpp:107
#14 0x00007fdbc93d29f5 in QDeclarativeObjectScriptClass::setProperty (this=0x1522630, obj=0x362d840, name=<optimized out>, value=..., context=0x7fdb2eccb0a0, evalContext=0x324bca0) at qml/qdeclarativeobjectscriptclass.cpp:429
#15 0x00007fdbc3aae718 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#16 0x00007fdbc3985d8f in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#17 0x00007fdb2f122341 in ?? ()
#18 0x0000000000000000 in ?? ()

Possible duplicates by query: bug 327350, bug 327091, bug 327019, bug 327016, bug 326905.

Reported using DrKonqi
Comment 1 goran 2014-01-01 00:18:23 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
Comment 2 Harald Sitter 2014-01-13 15:59:28 UTC
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).
Comment 3 Harald Sitter 2014-01-14 03:15:04 UTC
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.
Comment 4 Harald Sitter 2014-01-28 09:21:31 UTC
*** Bug 330477 has been marked as a duplicate of this bug. ***
Comment 5 Aleix Pol 2016-09-14 10:21:46 UTC
I'm pretty sure this was fixed at some point in libqapt. Otherwise, please ask your distributor to adopt the PackageKit backend.
Comment 6 Andrew Crouthamel 2018-09-26 22:09:33 UTC
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!
Comment 7 Andrew Crouthamel 2018-10-27 02:45:24 UTC
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!