Bug 505245 - Discover crashes when Flathub app update has a replacement
Summary: Discover crashes when Flathub app update has a replacement
Status: RESOLVED FIXED
Alias: None
Product: Discover
Classification: Applications
Component: discover (other bugs)
Version First Reported In: 6.4.80
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2025-06-05 16:50 UTC by Akseli Lahtinen
Modified: 2025-06-09 14:15 UTC (History)
3 users (show)

See Also:
Latest Commit: https://invent.kde.org/plasma/discover/-/commit/d0a2247567523ca77d880347cde926dad4ca43c5
Version Fixed In: 6.4.0
Sentry Crash Report: https://crash-reports.kde.org/organizations/kde/issues/193579/events/cf139f64c4fc424795021dd759c8bf3a/

Attachments
New crash information added by DrKonqi (113.11 KB, text/plain)
2025-06-05 16:50 UTC, Akseli Lahtinen 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Akseli Lahtinen 2025-06-05 16:50:25 UTC 
Application: plasma-discover (6.4.80)
 (Compiled from sources)
ApplicationNotResponding [ANR]: false
Qt Version: 6.9.0
Frameworks Version: 6.15.0
Operating System: Linux 6.15.0-61.fc43.x86_64 x86_64
Windowing System: Wayland
Distribution: "Fedora Linux 42 (KDE Plasma Desktop Edition)"
DrKonqi: 6.4.80 [CoredumpBackend]

-- Information about the crash:
An application I have, in this case "Luanti", has replacement available.

When I try to update, I get popup that says "Replacement available" popup:

"app:/net.minetest.Minetest/x86_64/stable" is no longer receiving updates.
Replace it with supported version provided by "app/org.luanti.luanti/x86_64/stable"?

When I press proceed, Discover tries to start updating and crashes.

The crash can be reproduced every time.

-- Backtrace (Reduced):
#4  __pthread_kill_implementation (threadid=<optimized out>, signo=6, no_tid=<optimized out>) at pthread_kill.c:44
#5  0x00007f23f2627afe in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26
#6  0x00007f23f260f6d0 in __GI_abort () at abort.c:73
#7  0x00007f23f2c1abfc in qAbort () at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/global/qassert.cpp:46
#8  0x00007f23f2c6e308 in qt_message_fatal<QString&> (context=<optimized out>, message=...) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/global/qlogging.cpp:2122
[...]
#10 0x00007f23f2c1c334 in QMessageLogger::fatal (this=this@entry=0x7f22e8df7620, msg=msg@entry=0x7f23f30e8438 "ASSERT: \"%s\" in file %s, line %d") at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/global/qlogging.cpp:883
#11 0x00007f23f2c1ac5b in qt_assert (assertion=<optimized out>, file=<optimized out>, line=<optimized out>) at /usr/src/debug/qt6-qtbase-6.9.0-2.fc42.x86_64/src/corelib/global/qassert.cpp:105
#12 0x00007f23740bdc67 in FlatpakTransactionThread::setCurrentRef (this=0x27ccee60, ref_cstr=0x7f22cc10c900 "app/org.luanti.luanti/x86_64/stable") at /home/akseli/Repositories/kde/src/discover/libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.cpp:520
#13 0x00007f23740b9942 in FlatpakTransactionThread::new_operation_cb (operation=0x7f22cc163ce0, progress=0x7f22cc1d2e40, user_data=0x27ccee60) at /home/akseli/Repositories/kde/src/discover/libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.cpp:64
#14 0x00007f23ef48a056 in ffi_call_unix64 () at ../src/x86/unix64.S:104
#15 0x00007f23ef485d08 in ffi_call_int (cif=cif@entry=0x7f22e8df7c60, fn=fn@entry=0x7f23740b9906 <FlatpakTransactionThread::new_operation_cb(_FlatpakTransaction*, _FlatpakTransactionOperation*, _FlatpakTransactionProgress*, void*)>, rvalue=<optimized out>, rvalue@entry=0x7f22e8df7bc0, avalue=avalue@entry=0x7f22e8df7b60, closure=closure@entry=0x0) at ../src/x86/ffi64.c:673
#16 0x00007f23ef48870e in ffi_call (cif=cif@entry=0x7f22e8df7c60, fn=fn@entry=0x7f23740b9906 <FlatpakTransactionThread::new_operation_cb(_FlatpakTransaction*, _FlatpakTransactionOperation*, _FlatpakTransactionProgress*, void*)>, rvalue=rvalue@entry=0x7f22e8df7bc0, avalue=avalue@entry=0x7f22e8df7b60) at ../src/x86/ffi64.c:710
#21 0x00007f23f0943e23 in <emit signal '???' on instance ???> (instance=instance@entry=0x7f22cc0014d0, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3597
    #17 0x00007f23f092a93c in g_cclosure_marshal_generic_va (closure=<optimized out>, return_value=<optimized out>, instance=<optimized out>, args_list=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=<optimized out>) at ../gobject/gclosure.c:1653
    #18 0x00007f23f0943c52 in _g_closure_invoke_va (closure=0x7f22cc005960, return_value=0x0, instance=0x7f22cc0014d0, args=0x7f22e8df7f20, n_params=2, param_types=0x7f22ec02afe0) at ../gobject/gclosure.c:898
    #19 signal_emit_valist_unlocked (instance=instance@entry=0x7f22cc0014d0, signal_id=signal_id@entry=38, detail=detail@entry=0, var_args=var_args@entry=0x7f22e8df7f20) at ../gobject/gsignal.c:3438
    #20 0x00007f23f0943d68 in g_signal_emit_valist (instance=0x7f22cc0014d0, signal_id=38, detail=0, var_args=var_args@entry=0x7f22e8df7f20) at ../gobject/gsignal.c:3277
#22 0x00007f236df6818a in emit_new_op (self=0x7f22cc0014d0, op=0x7f22cc163ce0, progress=<optimized out>) at ../common/flatpak-transaction.c:3216
#23 _run_op_kind (self=0x7f22cc0014d0, op=0x7f22cc163ce0, remote_state=0x7f22cc0041b0, out_needs_prune=<synthetic pointer>, out_needs_triggers=<synthetic pointer>, out_needs_cache_drop=<synthetic pointer>, cancellable=<optimized out>, error=0x7f22e8df80b0) at ../common/flatpak-transaction.c:4761
#24 flatpak_transaction_real_run (self=0x7f22cc0014d0, cancellable=0x27cdd390, error=0x7f22e8df8318) at ../common/flatpak-transaction.c:5276


Reported using DrKonqi
Comment 1 Akseli Lahtinen 2025-06-05 16:50:26 UTC 
Created attachment 182051 [details]
New crash information added by DrKonqi

DrKonqi auto-attaching complete backtrace.
Comment 2 Akseli Lahtinen 2025-06-05 16:53:05 UTC 
Found the assert in journal:

Jun 05 19:49:57 fedora-desktop plasma-discover[7625]: ASSERT: "m_jobTransactionsByRef.contains(ref)" in file /home/akseli/Repositories/kde/src/discover/libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.cpp, line 520
Comment 3 TraceyC 2025-06-05 17:12:44 UTC 
I wasn't able to reproduce the crash on Discover built from git-master on Solus
The Luanti package was updated, however, I ran into a UX glitch

1. Installed the deprecated flatpak
flatpak install net.minetest.Minetest
Say no at the prompt to update the source

2. Launch Discover and check for updates
3. Click Yes on the "Replacement available" popup

Observed: 
When the update list refreshed, Luanti and the locale package were still shown as needing an update
Clicking on Update All resulted in an error popup with 2 errors
"net.minetest.Minetest.Locale/x86_64/stable is not installed" (listed twice)

This refreshes updates again and nothing is listed, as expected
Checking the installed flatpaks on command line, I see that Luanti *has* been updated and the source changed as I requested

Luanti  org.luanti.luanti  5.12.0  stable
Comment 4 Akseli Lahtinen 2025-06-05 17:21:52 UTC 
(In reply to TraceyC from comment #3)
> I wasn't able to reproduce the crash on Discover built from git-master on
> Solus

Are you using debug build or relwithdebinfo? Since it's an assert, it will only hit in debug build
Comment 5 TraceyC 2025-06-05 19:04:21 UTC 
(In reply to Akseli Lahtinen from comment #4)
> Are you using debug build or relwithdebinfo? Since it's an assert, it will
> only hit in debug build

No, I wasn't. I can test again on my other system in a bit.
Comment 6 Bug Janitor Service 2025-06-06 14:54:18 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/1110
Comment 7 Akseli Lahtinen 2025-06-09 14:09:15 UTC 
Git commit 1c6ff6894e551a53c387d9f9a9f0429f63442e50 by Akseli Lahtinen.
Committed on 09/06/2025 at 07:36.
Pushed by ngraham into branch 'master'.

FlatpakTransactionThread: Copy job to new ref after rebase

When rebasing, the transaction still has the reference of the old item.
When rebasing is done and we know the new ref, the reference we ask for
during the new_operation_cb sets the new reference as current. This
causes an assert to fail the transaction, since the transaction
has the reference for the old item, even the job is still the same job.

Possible fix for this is to just copy the job and insert new ref as key
to the m_jobTransactionsByRef map, with the copied job: The job is
the same job for both the old and new reference.

M  +4    -0    libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.cpp

https://invent.kde.org/plasma/discover/-/commit/1c6ff6894e551a53c387d9f9a9f0429f63442e50
Comment 8 Nate Graham 2025-06-09 14:12:14 UTC 
Git commit d0a2247567523ca77d880347cde926dad4ca43c5 by Nate Graham.
Committed on 09/06/2025 at 14:12.
Pushed by ngraham into branch 'Plasma/6.4'.

FlatpakTransactionThread: Copy job to new ref after rebase

When rebasing, the transaction still has the reference of the old item.
When rebasing is done and we know the new ref, the reference we ask for
during the new_operation_cb sets the new reference as current. This
causes an assert to fail the transaction, since the transaction
has the reference for the old item, even the job is still the same job.

Possible fix for this is to just copy the job and insert new ref as key
to the m_jobTransactionsByRef map, with the copied job: The job is
the same job for both the old and new reference.


(cherry picked from commit 1c6ff6894e551a53c387d9f9a9f0429f63442e50)

Co-authored-by: Akseli Lahtinen <akselmo@akselmo.dev>

M  +4    -0    libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.cpp

https://invent.kde.org/plasma/discover/-/commit/d0a2247567523ca77d880347cde926dad4ca43c5