Bug 460503

Summary:	Discover notifier crashes in flatpak_installation_create_monitor() every time on boot
Product:	[Applications] Discover	Reporter:	saunders
Component:	Notifier	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	crash	CC:	aleixpol, mikael79, nate, phil, swami
Priority:	HI	Keywords:	drkonqi, regression
Version First Reported In:	5.26.0
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=323151
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:	https://crash-reports.kde.org/organizations/kde/issues/306818/

Description saunders 2022-10-15 19:42:25 UTC

Application: DiscoverNotifier (5.26.0)
 (Compiled from sources)
Qt Version: 5.15.5
Frameworks Version: 5.99.0
Operating System: Linux 6.0.2 x86_64
Windowing System: X11
Distribution: "Gentoo Linux"
DrKonqi: 5.26.0 [KCrashBackend]

-- Information about the crash:
Since updating kde it crashes every single time I boot.

The crash can be reproduced every time.

-- Backtrace:
Application: Discover Notifier (DiscoverNotifier), signal: Segmentation fault

[KCrash Handler]
#4  0x00007fbb206684cb in flatpak_installation_create_monitor () at /usr/lib64/libflatpak.so.0
#5  0x00007fbb20eec0e5 in  () at /usr/lib64/qt5/plugins/discover-notifier/FlatpakNotifier.so
#6  0x00007fbb20eec177 in  () at /usr/lib64/qt5/plugins/discover-notifier/FlatpakNotifier.so
#7  0x00007fbb20eec651 in  () at /usr/lib64/qt5/plugins/discover-notifier/FlatpakNotifier.so
#8  0x00005583a0c0a2cd in  ()
#9  0x00007fbb272adc36 in QObject::event(QEvent*) () at /usr/lib64/libQt5Core.so.5
#10 0x00007fbb28163a5f in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5
#11 0x00007fbb27282278 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5
#12 0x00007fbb27285905 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib64/libQt5Core.so.5
#13 0x00007fbb272d4b13 in  () at /usr/lib64/libQt5Core.so.5
#14 0x00007fbb261820cb in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
#15 0x00007fbb26182388 in  () at /usr/lib64/libglib-2.0.so.0
#16 0x00007fbb2618243f in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
#17 0x00007fbb272d45a4 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5
#18 0x00007fbb27280c5b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5
#19 0x00007fbb272892bd in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5
#20 0x00005583a0c081da in  ()
#21 0x00007fbb26e4f34a in  () at /lib64/libc.so.6
#22 0x00007fbb26e4f3fc in __libc_start_main () at /lib64/libc.so.6
#23 0x00005583a0c08361 in  ()
[Inferior 1 (process 4718) detached]

Reported using DrKonqi

Comment 1 Nate Graham 2022-10-16 01:23:06 UTC

Thanks for bug bug report. Would you be able to compile with debug symbols for Flatpak and Discover's Flatpak backend  and attach a new symbolicated backtrace so we can get a better look? Thanks!

Also, is this a regression compared to Plasma 5.25? Or was it happening there too?

Comment 2 saunders 2022-10-16 03:29:18 UTC

worked in 5.25

Comment 3 saunders 2022-10-19 06:56:24 UTC

I didn't get a better debug but I did find the problem.

Found out if I start "/usr/lib64/libexec/DiscoverNotifier" manually after booting everything is good. Turns out the issue was one of my drives mounts after DiscoverNotifier runs. That drive is where I keep most flatpak files.

I fixed the issue and now it loads every time. You can delete this.

Comment 4 Aleix Pol 2022-10-19 13:42:44 UTC

Thanks for looking into this, glad that everything works now.

Comment 5 Nate Graham 2022-10-19 13:46:24 UTC

Seems like a new instance of the age-old automount race condition. Can we make the Notifier run only after all automounted volumes have been automounted?

Comment 6 Aleix Pol 2022-10-20 12:11:48 UTC

I would expect that the autostart processes wouldn't get started after automount has happened at all.

I don't think it's Discover-specific by any means and I'm unsure how this automount works.

Comment 7 Nate Graham 2022-10-20 14:14:20 UTC

(In reply to Aleix Pol from comment #6)
> I would expect that the autostart processes wouldn't get started after
> automount has happened at all.
It does though, that's the bug. It causes other issues, not just this. So this is indeed not a Discover-specific issue, but rather a general one.

Found the bug report for it: Bug 323151.

*** This bug has been marked as a duplicate of bug 323151 ***

Comment 8 saunders 2022-10-20 16:22:22 UTC

I have a custom setup I wrote to do full disk encryption. The encrypted drive with the flatpack files is mounted after the main drive has booted, and I thought I had it unencrypting high enough up the chain to avoid issues like this. Apparently not. So I wrote a boot level init script and now all is well.

So yeah, this one was very much unique to me.

Comment 9 Nate Graham 2023-01-04 19:53:34 UTC

*** Bug 463070 has been marked as a duplicate of this bug. ***

Comment 10 Nate Graham 2023-03-13 17:01:40 UTC

*** Bug 467012 has been marked as a duplicate of this bug. ***

Comment 11 Nate Graham 2023-12-12 17:44:20 UTC

*** Bug 478334 has been marked as a duplicate of this bug. ***

Comment 12 David Edmundson 2025-11-05 10:00:30 UTC

*** Bug 511602 has been marked as a duplicate of this bug. ***

Comment 13 Nate Graham 2025-12-09 17:09:46 UTC

Years later we're no closer to implementing Bug 323151, and according to sentry, the issue is escalating, with 25k crashes in the last month. The race condition thing may have been a red herring. Un-duping and raising priority.

Comment 14 Nate Graham 2025-12-09 17:16:41 UTC

Looks like a fix for this was just released in Plasma 6.5.4, tracked by Bug 493686. Duping to that until and unless we get evidence that it's still happening.

*** This bug has been marked as a duplicate of bug 493686 ***