SUMMARY "Check For update" cause the crash for kded5 under Debian testing branch STEPS TO REPRODUCE 1. Open the discover or apper 2. Check for updates OBSERVED RESULT The kded5 crashes, causing many icons disappeared. EXPECTED RESULT Work normally. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.6 Kernel Version: 6.0.0-6-amd64 (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION Below is the log file of the software as debian didn't package dbg package for apper. QCommandLineParser: already having an option named "h" QCommandLineParser: already having an option named "help-all" QCommandLineParser: already having an option named "v" QCommandLineParser: option not defined: "install-provide-file" apper: apper: apper: PackageKit::Transaction::RoleGetUpdates "" void PackageModel::clear() packagekitqt.transaction: Unknown Transaction property: "Sender" QVariant(QString, ":1.475") void PackageModel::finished() PackageKit::Transaction(0x55b87be07df0) PackageKit::Transaction(0x55b87be07df0) apper: updates has changes false apper: updates has changes false apper.lib: PackageKit::Transaction::StatusUnknown PackageKit::Transaction::RoleRefreshCache packagekitqt.transaction: Unknown Transaction property: "Sender" QVariant(QString, ":1.475") kf.kwidgetsaddons: Invalid pixmap specified. kf.kwidgetsaddons: Invalid pixmap specified. kf.kwidgetsaddons: Invalid pixmap specified. kf.kwidgetsaddons: Invalid pixmap specified. kf.kwidgetsaddons: Invalid pixmap specified. kf.kwidgetsaddons: Invalid pixmap specified. kf.kwidgetsaddons: Invalid pixmap specified. kf.kwidgetsaddons: Invalid pixmap specified. apper.lib: PackageKit::Transaction::ExitSuccess PackageKit::Transaction::RoleRefreshCache apper.lib: 0 void PackageModel::clear() packagekitqt.transaction: Unknown Transaction property: "Sender" QVariant(QString, ":1.475") void PackageModel::finished() PackageKit::Transaction(0x55b87bd29e70) PackageKit::Transaction(0x55b87bd29e70) apper: updates has changes false apper: updates has changes false
Created attachment 155001 [details] kded5 backtrace I think I have the same problem and I am able to provide a bit more detail about it. The problem seems to occur when the apper background service finds new updates, e.g. apper check for updates, Discover check for updates, or periodic checks configured by kcm_updates. I think that it doesn't always happen, perhaps if the package cache is already updated by another package manager e.g. apt-get. gdb against the core dump shows this is where the SIGSEGV occurs in Thread #1: #3 0x00007f555edf9bd9 in KCrash::defaultCrashHandler(int) (sig=11) at ./src/kcrash.cpp:632 crashRecursionCounter = 2 #4 0x00007f555e391f90 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6 #5 0x00007f5508377ba4 in PackageKit::Transaction::role() const (this=this@entry=0x558e597802b0) at ./src/transaction.cpp:297 d = 0x29c704afb29f #6 0x00007f550880daae in TransactionWatcher::watchTransaction(QDBusObjectPath const&, bool) (this=this@entry=0x558e5993d170, tid=..., interactive=interactive@entry=false) at ./apperd/TransactionWatcher.cpp:104 transaction = 0x558e597802b0 #7 0x00007f550880db99 in TransactionWatcher::transactionListChanged(QStringList const&) (this=0x558e5993d170, tids=<optimized out>) at ./apperd/TransactionWatcher.cpp:85 tid = @0x7f554c00d190: {d = 0x558e5993d1b0} __for_range = <optimized out> There are several other instances with backtraces at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026062
Created attachment 155005 [details] /var/log/sylog The previous BT was captured from the initial session load of kded5 during the first login from a freshly booted machine. It is the first of a burst of approx 20 kded5 crash/restarts. Attached here is /var/log/syslog starting just before the traced crash, up until kded5 finally loaded. $ ls -lrt /var/lib/systemd/coredump/ -rw-r-----+ 1 root root 5118337 Jan 3 16:03 core.kded5.1000.54af227a14854e87bbf39456d86ce141.2226.1672761812000000.zst -rw-r-----+ 1 root root 5302957 Jan 3 16:08 core.kded5.1000.54af227a14854e87bbf39456d86ce141.3608.1672762116000000.zst -rw-r-----+ 1 root root 5135583 Jan 3 16:08 core.kded5.1000.54af227a14854e87bbf39456d86ce141.6873.1672762129000000.zst -rw-r-----+ 1 root root 5137317 Jan 3 16:09 core.kded5.1000.54af227a14854e87bbf39456d86ce141.6984.1672762139000000.zst -rw-r-----+ 1 root root 5138269 Jan 3 16:09 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7068.1672762154000000.zst -rw-r-----+ 1 root root 5135805 Jan 3 16:09 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7150.1672762165000000.zst -rw-r-----+ 1 root root 5140128 Jan 3 16:09 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7222.1672762180000000.zst -rw-r-----+ 1 root root 5132894 Jan 3 16:09 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7297.1672762191000000.zst -rw-r-----+ 1 root root 5122587 Jan 3 16:10 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7368.1672762203000000.zst -rw-r-----+ 1 root root 5127542 Jan 3 16:10 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7439.1672762219000000.zst -rw-r-----+ 1 root root 5184278 Jan 3 16:10 core.kded5.1000.54af227a14854e87bbf39456d86ce141.3212.1672762219000000.zst -rw-r-----+ 1 root root 5137850 Jan 3 16:10 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7511.1672762245000000.zst -rw-r-----+ 1 root root 5111696 Jan 3 16:10 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7602.1672762255000000.zst -rw-r-----+ 1 root root 5136731 Jan 3 16:11 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7671.1672762264000000.zst -rw-r-----+ 1 root root 5128882 Jan 3 16:11 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7736.1672762274000000.zst -rw-r-----+ 1 root root 5138086 Jan 3 16:11 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7802.1672762290000000.zst -rw-r-----+ 1 root root 5131265 Jan 3 16:11 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7879.1672762307000000.zst -rw-r-----+ 1 root root 5131731 Jan 3 16:11 core.kded5.1000.54af227a14854e87bbf39456d86ce141.7977.1672762318000000.zst
> #4 0x00007f555e391f90 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6 > #5 0x00007f5508377ba4 in PackageKit::Transaction::role() const () at ./src/transaction.cpp:297 > #6 0x00007f550880daae in TransactionWatcher::watchTransaction(QDBusObjectPath const&, bool) () at ./apperd/TransactionWatcher.cpp:104 > #7 0x00007f550880db99 in TransactionWatcher::transactionListChanged(QStringList const&) () at ./apperd/TransactionWatcher.cpp:85 > ... That backtrace looks similar to bug #462706 or bug #463626. And at Debian side: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026062
Bug #462706 states this to be no issue in kded framework and closed RESOLVED UPSTREAM. Therefore this issue was opened: https://github.com/PackageKit/PackageKit-Qt/issues/42 There it was stated that "TransactionWatcher.cpp comes from apper". And the events described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026062#35 might boil down to this question: Is it allowed for packagekit-qt to call deleteLater while still in the constructor (as far as I see it fails because it has role Transaction::RoleUnknown), or has TransactionWatcher to cope with this and e.g. not store such a "failed" Transaction in m_transactions?
*** Bug 463626 has been marked as a duplicate of this bug. ***
*** Bug 463609 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 462706 ***