Fedora 41 KDE Plasma - Journald Browser faults and dies during initialization

I noticed this maybe a week or two ago. I Fire up Journald Browser and I get the “bouncing thing by your mouse pointer” for maybe 3 or 4 seconds, and then nothing.

I’ve confirmed that this worked fine if I boot into the Live USB from the official release back in November/December of 2024. In that case, Journald Browser’s GUI pops up in less than a second.

It’s happening on a multiple systems: a 15 year old Intel box, a 1 year old AMD miniPC, and a 5 year old Lenovo laptop. All with he latest updates installed.

Here’s what I see in /var/log/messages on the Mini PC:

Jan 12 15:17:04 fedora systemd[2043]: Started app-org.kde.kjournaldbrowser@bce9a11b3ba341e38d5d5a0ab644edc8.service - Journald Browser - Journald B
rowser.
Jan 12 15:17:04 fedora wpa_supplicant[1352]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-56 noise=9999 txrate=234000
Jan 12 15:17:05 fedora audit[6629]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=662
9 comm=“kjournaldbrowse” exe=“/usr/bin/kjournaldbrowser” sig=11 res=1
Jan 12 15:17:05 fedora kernel: kjournaldbrowse[6629]: segfault at 4 ip 00007fdbffa250b8 sp 00007fff25d94068 error 4 in libQt6Core.so.6.8.1[2250b8,7
fdbff801000+420000] likely on CPU 10 (core 5, socket 0)
Jan 12 15:17:05 fedora kernel: Code: 94 c0 c3 90 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 8b 07 a8 01 74 0d 0f b6 c0 c1 e8 03 83 e0
01 c3 0f 1f 00 <8b> 40 04 c1 e8 03 83 e0 01 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f
Jan 12 15:17:05 fedora systemd-coredump[6647]: Process 6629 (kjournaldbrowse) of user 1000 terminated abnormally with signal 11/SEGV, processing…
Jan 12 15:17:05 fedora audit: BPF prog-id=149 op=LOAD
Jan 12 15:17:05 fedora audit: BPF prog-id=150 op=LOAD
Jan 12 15:17:05 fedora audit: BPF prog-id=151 op=LOAD
Jan 12 15:17:05 fedora systemd[1]: Started systemd-coredump@1-6647-0.service - Process Core Dump (PID 6647/UID 0).
Jan 12 15:17:05 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=‘unit=systemd-coredu
mp@1-6647-0 comm=“systemd” exe=“/usr/lib/systemd/systemd” hostname=? addr=? terminal=? res=success’

This line:
Jan 12 15:17:05 fedora kernel: kjournaldbrowse[6629]: segfault at 4 ip 00007fdbffa250b8 sp 00007fff25d94068 error 4 in libQt6Core.so.6.8.1[2250b8,7
fdbff801000+420000] likely on CPU 10 (core 5, socket 0)

seems to point to something in libQt6Core.so.
And, I do recall seeing an update into some Qt stuff around the time this happened.
As in I was getting updates via Discover, and on one, I clicked the button that gives more details and it showed a bunch of things that apparently were being patched and I recall seeing “Qt” in there a lot.

I did a lot of software dev and support in my career, but not on Linux or Unix.
Anyway, to reproduce it, I literally just launch “Journald Browser”.

Searching, I found nothing. So I figured I’d ask here.
Thanks in advance.

I tested kjournaldbrowser and it works without any crashing.

These are the versions I have tested:

rpm -qf /usr/lib64/libQt6Core.so.6.8.1
qt6-qtbase-6.8.1-8.fc41.aarch64
rpm -qf /usr/bin/kjournaldbrowser
kjournald-24.12.1-1.fc41.aarch64

Suggest you do a rpm verify to make sure that none of the installed files are damaged with (I think( rpm -aV and see what it reports.

Hi, thanks for the response and help.
I ran the rpm -aV and I didn’t see much (but I’ll paste it below).

As background, all three of my Fedora 41 KDE boxes are fresh installs from the 41 release, official ISO done in Nov/Dec 2024 (so not any possible “confusion” because of updates from Fedora 39 or 40, for instance.) And all three boxes have been taking all the patches offered (generally through Discover, but some rpm use as well).

The versions on my main box (the 1 year old miniPC) are:
Operating System: Fedora Linux 41
KDE Plasma Version: 6.2.5
KDE Frameworks Version: 6.10.0
Qt Version: 6.8.1
Kernel Version: 6.12.9-200.fc41.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7735HS with Radeon Graphics
Memory: 29.1 GiB of RAM
Graphics Processor: AMD Radeon 680M
Manufacturer: Micro Computer (HK) Tech Limited
Product Name: UM773 Lite
System Version: Version 1.0
and
rpm -qf /usr/lib64/libQt6Core.so.6.8.1
qt6-qtbase-6.8.1-10.fc41.x86_64
rpm -qf /usr/bin/kjournaldbrowser
kjournald-24.12.1-1.fc41.x86_64

There was an update just an hour ago that updated the qt6*.so is a little newer (but it didn’t resolve the fault/failure).
Here’s the output from the sudo rpm -aV:
sudo rpm -aV
[sudo] password for dlind:
…UG… g /var/run/avahi-daemon
.M… g /var/lib/boltd
…5…T. c /etc/yum.repos.d/_copr:copr.fedorainfracloud.org:phracek:PyCharm.repo
…5…T. c /etc/yum.repos.d/google-chrome.repo
…5…T. c /etc/yum.repos.d/rpmfusion-nonfree-nvidia-driver.repo
…5…T. c /etc/yum.repos.d/rpmfusion-nonfree-steam.repo
…G… /run/sddm
.M… /var/lib/sddm
…T. /boot/efi/EFI/BOOT/BOOTX64.EFI
…T. /boot/efi/EFI/BOOT/fbx64.efi
…T. /boot/efi/EFI/fedora/BOOTX64.CSV
…T. /boot/efi/EFI/fedora/mmx64.efi
…T. /boot/efi/EFI/fedora/shim.efi
…T. /boot/efi/EFI/fedora/shimx64.efi
…T. /boot/efi/EFI/BOOT/BOOTIA32.EFI
…T. /boot/efi/EFI/BOOT/fbia32.efi
…T. /boot/efi/EFI/fedora/BOOTIA32.CSV
…T. /boot/efi/EFI/fedora/mmia32.efi
…T. /boot/efi/EFI/fedora/shimia32.efi
.M… /boot/efi/System
.M… /boot/efi/System/Library
.M… /boot/efi/System/Library/CoreServices
.M…T. /boot/efi/System/Library/CoreServices/SystemVersion.plist
.M…T. /boot/efi/mach_kernel
S.5…T. c /etc/sysconfig/livesys
.M… g /var/lib/snapd/snap/README
.M… g /var/lib/snapd/state.json
…U… /etc/sssd
…U… /etc/sssd/conf.d
…U… /etc/sssd/pki
S.5…T. c /etc/printcap
S.5…T. c /etc/selinux/targeted/contexts/files/file_contexts.local

I’ve not seen this output before (so much to learn, heh). It looks like maybe the boot EFI stuff isn’t being updated?
Also, my main box is dual-booting to Windows 11 and Fedora but I’ve not seen any issues there at all. My ancient box is dual booting, but my laptop is a clean install with no dual booting… and they all show this issue.

And to be clear, this isn’t a huge issue for me. There’s still the command line log viewer (journalctl). I just wanted to give a heads up. And, interestingly, about 3 (or so) days ago, my laptop was not seeing the problem, but it was lagging behind in getting the updates by a week or so… I confirmed that before that update, the Journald Browser was working on the laptop, and then after I did the update, it didn’t work - it was seeing the problem.

Oh, and I did install the Chrome browser, so that might have “tainted” things. I use chrome on my Windows boxes and want to be able to sync bookmarks and history and things between my various boxes. And Chromium doesn’t sync with Chrome so… I’ve installed Chrome.

I am curious what you did with rpm?
Usually using dnf abd discover will always be consistent.

I don’t really suspect that I did anything via dnf that’s causing this weirdness (but, I’m not really proficient with dnf yet - lots of reading and talking with my more linux-knowledgable nephew).

dnf things I’ve done on my MiniPC box:
I added the repo for dl.winehq.org to try see what versions of wine they had (as the wine from the Fedora repository wasn’t working)
sudo dnf5 config-manager addrepo --from-repofile=https://dl.winehq.org/wine-builds/fedora/41/winehq.repo

I removed the “came with Fedora KDE” install of the non-flatpack LibreOffice via dnf and then added the flatpack versions through Discover
sudo dnf remove libreoffice*

I also installed a couple of tools:
sudo dnf install bmon
sudo dnf install iotop

I do use Discover for most things.
On my 14-year-old box, while trying to get wine to work, I know I did multiple rpm searches looking for a “-stable” version of wine via rpm and there wasn’t one. And I finally added a working wine via Discover (on the very old box).
And yeah, it was my understanding that command line dnf and GUI Discover were basically doing the same things to the same places - and would generally be “in sync”

You could add a fedora kde vm to your system and compare how it works to your failing hosts. Somewhere you have a bad .so I would guess.
Comparing a working vm to the broken host would be one way to find the problem .so…

I would use virt manager to create the vm.