Bug 1663726 - Discover 5.14.4 crashed when clicking on Checking for updates involving flatpak
Summary: Discover 5.14.4 crashed when clicking on Checking for updates involving flatpak
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-discover
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-07 02:17 UTC by Matt Fagnani
Modified: 2019-11-27 20:35 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-11-27 20:35:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
KDE Software Compilation 402848 0 None None None 2019-01-07 02:26:00 UTC

Description Matt Fagnani 2019-01-07 02:17:53 UTC
Description of problem:

I ran plasma-discover & in konsole to get the error messages as discover 5.14.4 had crashed twice in the same way when I clicked on the Checking for updates button in the lower left. discover crashed and drkonqi appeared. I reported this issue at https://bugs.kde.org/show_bug.cgi?id=402848 I attached the error message output, trace, and other files there.

About 50 notifications of Searching for file... appeared in the plasma notifications widget after discover crashed. Each file found by those searches appeared to be a package name. Some example names started with plasma-, qt5-, fedora-. Other notifications included two Resolving... and one Refreshing package cache... which showed package names starting with NetworkManager-

The following is the trace of just the crashing thread which had a segmentation fault in QHttpNetworkConnectionChannel::sendRequest() at qhttpnetworkconnectionchannel.cpp:251.

-- Backtrace:
Application: Discover (plasma-discover), signal: Segmentation fault
Using host libthread_db library "/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0xb205b840 (LWP 4315))]
...
Thread 13 (Thread 0x9e13eb40 (LWP 4367)):
[KCrash Handler]
#8  0xb5bfd23b in QHttpNetworkConnectionChannel::sendRequest() (this=0xb0fc9094) at access/qhttpnetworkconnectionchannel.cpp:251
#9  0xb5bfba5b in QHttpNetworkConnectionPrivate::_q_startNextRequest() (this=0x9ec296d0) at access/qhttpnetworkconnection.cpp:1044
#10 0xb5823fc6 in QMetaCallEvent::placeMetaCall(QObject*) (object=0x9bf5d3e0, this=0xb0f3b350) at kernel/qobject.cpp:506
#11 0xb5823fc6 in QMetaCallEvent::placeMetaCall(QObject*) (this=0xb0f3b350, object=0x9bf5d3e0) at kernel/qobject.cpp:501
#12 0xb58274b3 in QObject::event(QEvent*) (this=0x9bf5d3e0, e=0xb0f3b350) at kernel/qobject.cpp:1251
#13 0xb689ad8a in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=0x1878310, receiver=0x9bf5d3e0, e=0xb0f3b350) at kernel/qapplication.cpp:3726
#14 0xb68a2e39 in QApplication::notify(QObject*, QEvent*) (this=0xbf8a3634, receiver=0x9bf5d3e0, e=0xb0f3b350) at kernel/qapplication.cpp:3485
#15 0xb57fbbb6 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x9bf5d3e0, event=0xb0f3b350) at kernel/qcoreapplication.cpp:1047
#16 0xb57ff068 in QCoreApplication::sendEvent(QObject*, QEvent*) (event=0xb0f3b350, receiver=<optimized out>) at kernel/qcoreapplication.h:234
#17 0xb57ff068 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (receiver=<optimized out>, event_type=<optimized out>, data=0x1ebdfd0) at kernel/qcoreapplication.cpp:1744
#18 0xb57ff47b in QCoreApplication::sendPostedEvents(QObject*, int) (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1598
#19 0xb5853167 in postEventSourceDispatch(GSource*, GSourceFunc, gpointer) (s=0x9c561ea0) at kernel/qeventdispatcher_glib.cpp:276
#20 0xb26e53f5 in g_main_dispatch (context=0xb0f79580) at gmain.c:3182
#21 0xb26e53f5 in g_main_context_dispatch (context=0xb0f79580) at gmain.c:3847
#22 0xb26e57d9 in g_main_context_iterate (context=context@entry=0xb0f79580, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3920
#23 0xb26e588b in g_main_context_iteration (context=0xb0f79580, may_block=1) at gmain.c:3981
#24 0xb5852e2d in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0xa1fa5250, flags=...) at kernel/qeventdispatcher_glib.cpp:422
#25 0xb57fa8bf in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=<optimized out>, flags=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:140
#26 0xb5663cb1 in QThread::exec() (this=0x381fb20) at ../../include/QtCore/../../src/corelib/global/qflags.h:120
#27 0xb5663d9c in QThread::run() (this=0x381fb20) at thread/qthread.cpp:592
#28 0xb566e7e9 in QThreadPrivate::start(void*) (arg=<optimized out>) at thread/qthread_unix.cpp:367
#29 0xb4e645de in start_thread (arg=<optimized out>) at pthread_create.c:486
#30 0xb527a97a in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108

I ran valgrind --leak-check=no --log-file=valgrind-discover-5.14.5-1.txt plasma-discover & The valgrind output following the crash showed an invalid read of size 4 in QHttpNetworkConnectionChannel::sendRequest() at qhttpnetworkconnectionchannel.cpp:251 like in the trace of the crashing thread.
The line "Address 0x0 is not stack'd, malloc'd or (recently) free'd" likely means a null pointer is involved and might be dereferenced leading to the segmentation fault.

==5133== Thread 9 QNetworkAccessMa:
==5133== Invalid read of size 4
==5133==    at 0x6AA623B: QHttpNetworkConnectionChannel::sendRequest() (qhttpnetworkconnectionchannel.cpp:251)
==5133==    by 0x6AA4A5A: QHttpNetworkConnectionPrivate::_q_startNextRequest() (qhttpnetworkconnection.cpp:1044)
==5133==    by 0x6F18FC5: placeMetaCall (qobject.cpp:506)
==5133==    by 0x6F18FC5: QMetaCallEvent::placeMetaCall(QObject*) (qobject.cpp:501)
==5133==    by 0x6F1C4B2: QObject::event(QEvent*) (qobject.cpp:1251)
==5133==    by 0x59ADD89: QApplicationPrivate::notify_helper(QObject*, QEvent*) (qapplication.cpp:3726)
==5133==    by 0x59B5E38: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:3485)
==5133==    by 0x6EF0BB5: QCoreApplication::notifyInternal2(QObject*, QEvent*) (qcoreapplication.cpp:1047)
==5133==    by 0x6EF4067: sendEvent (qcoreapplication.h:234)
==5133==    by 0x6EF4067: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (qcoreapplication.cpp:1744)
==5133==    by 0x6EF447A: QCoreApplication::sendPostedEvents(QObject*, int) (qcoreapplication.cpp:1598)
==5133==    by 0x6F48166: postEventSourceDispatch(_GSource*, int (*)(void*), void*) (qeventdispatcher_glib.cpp:276)
==5133==    by 0x9FED3F4: g_main_dispatch (gmain.c:3182)
==5133==    by 0x9FED3F4: g_main_context_dispatch (gmain.c:3847)
==5133==    by 0x9FED7D8: g_main_context_iterate.isra.20 (gmain.c:3920)
==5133==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Two invalid reads of size 2 in socketNotifierSourceCheck at qeventdispatcher_glib.cpp:88 and qeventdispatcher_glib.cpp:79 appear to be use-after-free errors since they have lines like "Address 0xcbdff66 is 6 bytes inside a block of size 12 free'd" Invalid data from those errors might lead to the crash.

==5133== Thread 3 QDBusConnectionM:
==5133== Invalid read of size 2
==5133==    at 0x6F47CCC: socketNotifierSourceCheck(_GSource*) (qeventdispatcher_glib.cpp:88)
==5133==    by 0x9FED0F1: g_main_context_check (gmain.c:3753)
==5133==    by 0x9FED6E4: g_main_context_iterate.isra.20 (gmain.c:3917)
==5133==    by 0x9FED88A: g_main_context_iteration (gmain.c:3981)
==5133==    by 0x6F47E2C: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventdispatcher_glib.cpp:422)
==5133==    by 0x6EEF8BE: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:214)
==5133==    by 0x6D58CB0: QThread::exec() (qthread.cpp:525)
==5133==    by 0x580C0CF: QDBusConnectionManager::run() (qdbusconnection.cpp:178)
==5133==    by 0x6D637E8: QThreadPrivate::start(void*) (qthread_unix.cpp:367)
==5133==    by 0x78FD5DD: start_thread (pthread_create.c:486)
==5133==    by 0x7527979: clone (clone.S:108)
==5133==  Address 0xcbdff66 is 6 bytes inside a block of size 12 free'd
==5133==    at 0x4836D85: operator delete(void*, unsigned int) (vg_replace_malloc.c:591)
==5133==    by 0x6F485DF: QEventDispatcherGlib::unregisterSocketNotifier(QSocketNotifier*) (qeventdispatcher_glib.cpp:503)
==5133==    by 0x6F27AF1: QSocketNotifier::setEnabled(bool) (qsocketnotifier.cpp:246)
==5133==    by 0x6F47CC4: socketNotifierSourceCheck(_GSource*) (qeventdispatcher_glib.cpp:88)
==5133==    by 0x9FED0F1: g_main_context_check (gmain.c:3753)
==5133==    by 0x9FED6E4: g_main_context_iterate.isra.20 (gmain.c:3917)
==5133==    by 0x9FED88A: g_main_context_iteration (gmain.c:3981)
==5133==    by 0x6F47E2C: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventdispatcher_glib.cpp:422)
==5133==    by 0x6EEF8BE: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:214)
==5133==    by 0x6D58CB0: QThread::exec() (qthread.cpp:525)
==5133==    by 0x580C0CF: QDBusConnectionManager::run() (qdbusconnection.cpp:178)
==5133==    by 0x6D637E8: QThreadPrivate::start(void*) (qthread_unix.cpp:367)
==5133==  Block was alloc'd at
==5133==    at 0x4835C89: operator new(unsigned int) (vg_replace_malloc.c:338)
==5133==    by 0x6F484AC: QEventDispatcherGlib::registerSocketNotifier(QSocketNotifier*) (qeventdispatcher_glib.cpp:459)
==5133==    by 0x6F279E5: QSocketNotifier::QSocketNotifier(int, QSocketNotifier::Type, QObject*) (qsocketnotifier.cpp:155)
==5133==    by 0x58174F8: qDBusAddWatch (qdbusintegrator.cpp:213)
==5133==    by 0x7B41688: _dbus_watch_list_set_functions (in /usr/lib/libdbus-1.so.3.19.8)
==5133==    by 0x7B25219: dbus_connection_set_watch_functions (in /usr/lib/libdbus-1.so.3.19.8)
==5133==    by 0x581A00A: q_dbus_connection_set_watch_functions (qdbus_symbols_p.h:229)
==5133==    by 0x581A00A: QDBusConnectionPrivate::setConnection(DBusConnection*, QDBusErrorInternal const&) (qdbusintegrator.cpp:1794)
==5133==    by 0x580E6F7: QDBusConnectionManager::executeConnectionRequest(QDBusConnectionManager::ConnectionRequestData*) (qdbusconnection.cpp:289)
==5133==    by 0x6F18F63: call (qobjectdefs_impl.h:376)
==5133==    by 0x6F18F63: QMetaCallEvent::placeMetaCall(QObject*) (qobject.cpp:504)
==5133==    by 0x6F1C4B2: QObject::event(QEvent*) (qobject.cpp:1251)
==5133==    by 0x6D58DDA: QThread::event(QEvent*) (qthread.cpp:832)
==5133==    by 0x6EF0B11: doNotify(QObject*, QEvent*) (qcoreapplication.cpp:1137)
==5133== 
==5133== Invalid read of size 2
==5133==    at 0x6F47C30: socketNotifierSourceCheck(_GSource*) (qeventdispatcher_glib.cpp:79)
==5133==    by 0x9FED0F1: g_main_context_check (gmain.c:3753)
==5133==    by 0x9FED6E4: g_main_context_iterate.isra.20 (gmain.c:3917)
==5133==    by 0x9FED88A: g_main_context_iteration (gmain.c:3981)
==5133==    by 0x6F47E2C: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventdispatcher_glib.cpp:422)
==5133==    by 0x6EEF8BE: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:214)
==5133==    by 0x6D58CB0: QThread::exec() (qthread.cpp:525)
==5133==    by 0x580C0CF: QDBusConnectionManager::run() (qdbusconnection.cpp:178)
==5133==    by 0x6D637E8: QThreadPrivate::start(void*) (qthread_unix.cpp:367)
==5133==    by 0x78FD5DD: start_thread (pthread_create.c:486)
==5133==    by 0x7527979: clone (clone.S:108)
==5133==  Address 0xcbdff64 is 4 bytes inside a block of size 12 free'd
==5133==    at 0x4836D85: operator delete(void*, unsigned int) (vg_replace_malloc.c:591)
==5133==    by 0x6F485DF: QEventDispatcherGlib::unregisterSocketNotifier(QSocketNotifier*) (qeventdispatcher_glib.cpp:503)
==5133==    by 0x6F27AF1: QSocketNotifier::setEnabled(bool) (qsocketnotifier.cpp:246)
==5133==    by 0x6F47CC4: socketNotifierSourceCheck(_GSource*) (qeventdispatcher_glib.cpp:88)
==5133==    by 0x9FED0F1: g_main_context_check (gmain.c:3753)
==5133==    by 0x9FED6E4: g_main_context_iterate.isra.20 (gmain.c:3917)
==5133==    by 0x9FED88A: g_main_context_iteration (gmain.c:3981)
==5133==    by 0x6F47E2C: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventdispatcher_glib.cpp:422)
==5133==    by 0x6EEF8BE: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:214)
==5133==    by 0x6D58CB0: QThread::exec() (qthread.cpp:525)
==5133==    by 0x580C0CF: QDBusConnectionManager::run() (qdbusconnection.cpp:178)
==5133==    by 0x6D637E8: QThreadPrivate::start(void*) (qthread_unix.cpp:367)
==5133==  Block was alloc'd at
==5133==    at 0x4835C89: operator new(unsigned int) (vg_replace_malloc.c:338)
==5133==    by 0x6F484AC: QEventDispatcherGlib::registerSocketNotifier(QSocketNotifier*) (qeventdispatcher_glib.cpp:459)
==5133==    by 0x6F279E5: QSocketNotifier::QSocketNotifier(int, QSocketNotifier::Type, QObject*) (qsocketnotifier.cpp:155)
==5133==    by 0x58174F8: qDBusAddWatch (qdbusintegrator.cpp:213)
==5133==    by 0x7B41688: _dbus_watch_list_set_functions (in /usr/lib/libdbus-1.so.3.19.8)
==5133==    by 0x7B25219: dbus_connection_set_watch_functions (in /usr/lib/libdbus-1.so.3.19.8)
==5133==    by 0x581A00A: q_dbus_connection_set_watch_functions (qdbus_symbols_p.h:229)
==5133==    by 0x581A00A: QDBusConnectionPrivate::setConnection(DBusConnection*, QDBusErrorInternal const&) (qdbusintegrator.cpp:1794)
==5133==    by 0x580E6F7: QDBusConnectionManager::executeConnectionRequest(QDBusConnectionManager::ConnectionRequestData*) (qdbusconnection.cpp:289)
==5133==    by 0x6F18F63: call (qobjectdefs_impl.h:376)
==5133==    by 0x6F18F63: QMetaCallEvent::placeMetaCall(QObject*) (qobject.cpp:504)
==5133==    by 0x6F1C4B2: QObject::event(QEvent*) (qobject.cpp:1251)
==5133==    by 0x6D58DDA: QThread::event(QEvent*) (qthread.cpp:832)
==5133==    by 0x6EF0B11: doNotify(QObject*, QEvent*) (qcoreapplication.cpp:1137)

The packagekit daemon crashed right before discover crashed as shown in the following output.

Transaction error:  PackageKit::Transaction::Error(ErrorProcessKill) "The PackageKit daemon has crashed" PackageKit::Transaction(0xc30c550)
Transaction error:  "The PackageKit daemon has crashed" PackageKit::Transaction(0x1e2268a8)
failed PackageKit::Transaction::Exit(ExitKilled) PackageKit::Transaction(0x1e2268a8)
Transaction error:  "The PackageKit daemon has crashed" PackageKit::Transaction(0xc1aa0b8)
failed PackageKit::Transaction::Exit(ExitKilled) PackageKit::Transaction(0xc1aa0b8)
PackageKit stopped running!
Transaction error:  PackageKit::Transaction::Error(ErrorInternalError) "No such interface “org.freedesktop.PackageKit.Transaction” on object at path /29621_bbdbecad" PackageKit::Transaction(0xc30c550)
Transaction error:  "No such interface “org.freedesktop.PackageKit.Transaction” on object at path /29674_edacebda" PackageKit::Transaction(0x1e2268a8)
failed PackageKit::Transaction::Exit(ExitFailed) PackageKit::Transaction(0x1e2268a8)
Transaction error:  "No such interface “org.freedesktop.PackageKit.Transaction” on object at path /29675_eeeedbaa" PackageKit::Transaction(0xc1aa0b8)
failed PackageKit::Transaction::Exit(ExitFailed) PackageKit::Transaction(0xc1aa0b8)
KCrash: Application 'plasma-discover' crashing...
KCrash: Attempting to start /usr/libexec/drkonqi from kdeinit

The packagekitd crash was not shown in the error messages of the first crash.

I ran gdb plasma-discover. The segmentation fault was shown as

Thread 79 "QNetworkAccessM" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x9c9ffb40 (LWP 2647)]
0xb5c9c23b in QHttpNetworkConnectionChannel::sendRequest (this=0x9ce0b114)
    at access/qhttpnetworkconnectionchannel.cpp:251
251         return protocolHandler->sendRequest();

protocolHandler and its component object had null pointers as follows.

(gdb) p protocolHandler
$1 = {d = 0x0}
(gdb) p protocolHandler.d
$2 = (QAbstractProtocolHandler *) 0x0

protocolHandler->sendRequest() seemed to be a null pointer dereference resulting in the segmentation fault at qhttpnetworkconnectionchannel.cpp:251 in qt5-qtbase. https://code.qt.io/cgit/qt/qtbase.git/tree/src/network/access/qhttpnetworkconnectionchannel.cpp?h=5.11.3 shows the QHttpNetworkConnectionChannel::sendRequest as

bool QHttpNetworkConnectionChannel::sendRequest()
{
    Q_ASSERT(!protocolHandler.isNull());
    return protocolHandler->sendRequest();
}

The assertion that protocolHandler wasn't null not being satisfied wasn't shown in the output.

I saw two other segmentation faults in gdb which occurred after the one above involving gpgme, flatpak, and ostree on two different runs. I suppose they involved checking of the GPG signatures for flatpak remotes.

Thread 13 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa2969b40 (LWP 3076)]
0xa336255f in _gpgme_debug_buffer () from /lib/libgpgme.so.11
(gdb) bt
#0  0xa336255f in _gpgme_debug_buffer () at /lib/libgpgme.so.11
#1  0xa335f7dc in _gpgme_io_read () at /lib/libgpgme.so.11
#2  0xa336586e in _gpgme_get_program_version () at /lib/libgpgme.so.11
#3  0xa3350184 in gpg_get_version () at /lib/libgpgme.so.11
#4  0xa334df9d in _gpgme_set_engine_info () at /lib/libgpgme.so.11
#5  0xa3364b4e in gpgme_ctx_set_engine_info () at /lib/libgpgme.so.11
#6  0xa3215493 in  () at /lib/libostree-1.so.1
#7  0xa3201f53 in  () at /lib/libostree-1.so.1
#8  0xa31a5c46 in  () at /lib/libostree-1.so.1
#9  0xa31ae378 in  () at /lib/libostree-1.so.1
#10 0xa31aec3a in ostree_repo_verify_summary () at /lib/libostree-1.so.1
#11 0xa31d09c1 in ostree_repo_remote_fetch_summary_with_options ()
    at /lib/libostree-1.so.1
#12 0xa31a88f2 in ostree_repo_remote_fetch_summary () at /lib/libostree-1.so.1
#13 0xa33f5ae1 in  () at /lib/libflatpak.so.0
#14 0xa33f62e4 in  () at /lib/libflatpak.so.0
#15 0xa343b4ea in flatpak_installation_list_remote_refs_sync ()
    at /lib/libflatpak.so.0
#16 0xa343b7ae in flatpak_installation_list_installed_refs_for_update ()
    at /lib/libflatpak.so.0
#17 0xa34ac059 in  () at /usr/lib/qt5/plugins/discover/flatpak-backend.so
#18 0xb5704af0 in QThreadPoolThread::run() (this=<optimized out>)
    at thread/qthreadpool.cpp:101
#19 0xb570d7e9 in QThreadPrivate::start(void*) (arg=<optimized out>)
    at thread/qthread_unix.cpp:367
#20 0xb4f035de in start_thread (arg=<optimized out>) at pthread_create.c:486
#21 0xb531997a in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108
(gdb) bt
#0  0xa336255f in _gpgme_debug_buffer () at /lib/libgpgme.so.11
#1  0xa335f7dc in _gpgme_io_read () at /lib/libgpgme.so.11
#2  0xa336586e in _gpgme_get_program_version () at /lib/libgpgme.so.11
#3  0xa3350184 in gpg_get_version () at /lib/libgpgme.so.11
#4  0xa334df9d in _gpgme_set_engine_info () at /lib/libgpgme.so.11
#5  0xa3364b4e in gpgme_ctx_set_engine_info () at /lib/libgpgme.so.11
#6  0xa3215493 in  () at /lib/libostree-1.so.1
#7  0xa3201f53 in  () at /lib/libostree-1.so.1
#8  0xa31a5c46 in  () at /lib/libostree-1.so.1
#9  0xa31ae378 in  () at /lib/libostree-1.so.1
#10 0xa31aec3a in ostree_repo_verify_summary () at /lib/libostree-1.so.1
#11 0xa31d09c1 in ostree_repo_remote_fetch_summary_with_options ()
    at /lib/libostree-1.so.1
#12 0xa31a88f2 in ostree_repo_remote_fetch_summary () at /lib/libostree-1.so.1
#13 0xa33f5ae1 in  () at /lib/libflatpak.so.0
#14 0xa33f62e4 in  () at /lib/libflatpak.so.0
#15 0xa343b4ea in flatpak_installation_list_remote_refs_sync ()
    at /lib/libflatpak.so.0
#16 0xa343b7ae in flatpak_installation_list_installed_refs_for_update ()
    at /lib/libflatpak.so.0
#17 0xa34ac059 in  () at /usr/lib/qt5/plugins/discover/flatpak-backend.so
#18 0xb5704af0 in QThreadPoolThread::run() (this=<optimized out>)
    at thread/qthreadpool.cpp:101
#19 0xb570d7e9 in QThreadPrivate::start(void*) (arg=<optimized out>)
    at thread/qthread_unix.cpp:367
#20 0xb4f035de in start_thread (arg=<optimized out>) at pthread_create.c:486
--Type <RET> for more, q to quit, c to continue without paging--
#21 0xb531997a in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108

Thread 13 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa296ab40 (LWP 5956)]
0xa335e55f in _gpgme_debug_buffer (lvl=7, fmt=0xa3365b11 "%s: check: %s", 
    func=0xa3367b97 "_gpgme_io_read", buffer=0xa2969afc "", len=4294967295)
    at debug.c:393
393                   val = buffer[idx++];


I noticed discover output various errors for Fedora firefox, kde, gnome flatpak remotes I had added months ago using the flatpak cli. I removed the firefox, kde, gnome flatpak remotes in groups one at a time using flatpak remote-delete, but the same segmentation faults occurred though the error messages of the removed remotes no longer were shown. I removed the flathub remote which was the last remote I had added using the cli. After removing the flathub remote, the segmentation faults and crashes haven't occurred when I clicked on Checking for updates which showed that no updates were available. The segmentation faults seemed to be when sending requests for flatpak remote update information.  Something might have changed with the flatpak remotes or backend that triggered the crashes with the configuration I had. I added the flathub remote again in the settings part of discover, and discover didn't crash and showed No updates once though the checking for updates didn't seem to finish another time.

Version-Release number of selected component (if applicable):
flatpak-0:1.0.6-4.fc29.i686
gpgme-0:1.11.1-3.fc29.i686
ostree-0:2018.9-1.fc29.i686
plasma-discover-0:5.14.4-1.fc29.i686
qt5-qtbase-0:5.11.3-1.fc29.i686


How reproducible:
The crash occurred about 15 times until I removed all of the flatpak remotes. The crash hasn't happened in about 4 times I ran discover since I removed all the flatpak remotes then added flathub through settings in discover.

Steps to Reproduce:
1. for each address of gnome, kde, Fedora firefox, flathub flatpak remotes 
flatpak --user remote-add address
2. plasma-discover & (in konsole)
3. click Checking for updates


Actual results:
discover crashed when checking for updates


Expected results:
discover checks for updates without crashing


Additional info:

The crashes were segmentation faults in QHttpNetworkConnectionChannel::sendRequest() at access/qhttpnetworkconnectionchannel.cpp:251

The report at https://bugs.kde.org/show_bug.cgi?id=401825 also involved a segmentation fault at that line with a similar trace in F29 though the way in which that crash occurred was different.

Comment 1 Ben Cotton 2019-10-31 20:12:54 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 2 Ben Cotton 2019-11-27 20:35:32 UTC
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.