Kwallet5 and ksecretd crashes during boot

ARM
,
1

These two crash during boot after yesterday’s system updates. There are a couple new bug reports in KDE bug reporting system, assuming that they are related to this. Do anybody on x86 machines have anything similar?

The issue also affects Chromium (flatpak in my case), causing a very late start of the app. Kwallet was already disabled in my system so it doesn’t really matter if you use it or not.

3

There has been an update today but still crashes on every boot.

4

I had been updating Mon Wed and Fri each week but I will update each day in the future until it gets fixed.

1 Like
5

kwallet crashes stopped. But ksecretd crashes still happen on every boot. Probly related to:

https://bugs.kde.org/show_bug.cgi?id=504251
https://bugs.kde.org/show_bug.cgi?id=502808

6

Have you had time to test yesterday’s kwallet update yet

7

Yes. I tried to do some debugging using Grok and maybe it could be useful so i am pasting it here:

The provided coredumpctl output details a crash of the ksecretd process (PID 978) from a previous boot (3e8a1d6df9b749bc8711de6c1f5f0332) on May 19, 2025, at 10:00:10 +03, caused by a segmentation fault (SIGSEGV) in the Qt Cryptographic Architecture (QCA) library (libqca-qt6.so.2). This aligns with prior discussions about ksecretd instability and its impact on kwalletd6, which logged D-Bus errors due to ksecretd issues. As of 10:38 AM +03, May 19, 2025, your recent systemctl --user status output confirmed both ksecretd (PID 967) and kwalletd6 (PID 956) are running in the current boot (277cc2511996419fa1dd391007c22378). Below, I’ll analyze the crash, its implications for the current session, and provide steps to prevent recurrence, focusing on ksecretd and kwalletd6.

Analysis of ksecretd Crash (PID 978):

  1. Crash Details:
  • Process: ksecretd (PID 978, user: turker, UID/GID: 1000)
  • Signal: SIGSEGV (segmentation fault)
  • Timestamp: May 19, 2025, 10:00:10 +03 (38 minutes ago, prior boot)
  • Executable: /usr/bin/ksecretd
  • Unit: dbus-:1.1-org.kde.secretservicecompat@0.service
  • Stack Trace:

text

Copy

#0 0x0000ffff2bea70f8 n/a (libc.so.6 + 0x870f8) #1 0x0000ffff2be56f9c raise (libc.so.6 + 0x36f9c) #2 0x0000ffff2e184d24 _ZN6KCrash19defaultCrashHandlerEi (libKF6Crash.so.6 + 0x4d24) #3 0x0000ffff2e708828 n/a (ld-linux-aarch64.so.1 + 0x38828) #4 0x0000ffff2e708828 n/a (ld-linux-aarch64.so.1 + 0x38828) #5 0x0000ffff2e067e78 _ZN3QCA12MemoryRegionD1Ev (libqca-qt6.so.2 + 0x77e78) #6 0x0000ffff2beb6fac n/a (libc.so.6 + 0x96fac) #7 0x0000ffffc5a86190 n/a (n/a + 0x0)

  • Key Frame: The crash occurred in QCA::MemoryRegion::~MemoryRegion() (frame #5) from libqca-qt6.so.2, indicating a memory corruption or invalid pointer access during the destruction of a cryptographic memory region.
  • Architecture: AArch64 (ARM64), consistent with your system.
  1. Cause:
  • The segmentation fault in QCA::MemoryRegion::~MemoryRegion() suggests:
    • A bug in the QCA library (libqca-qt6.so.2), possibly specific to AArch64.
    • Memory corruption triggered by ksecretd handling a Secret Service request, likely from an app like Flatpak Chromium.
    • Possible interaction with corrupted wallet data from kwalletd6.
  • The crash was caught by KDE’s crash handler (KCrash::defaultCrashHandler), which raised the SIGSEGV.
  1. Relation to kwalletd6:
  • kwalletd6 (PID 956, current boot) relies on ksecretd for Secret Service API compatibility. The crash of ksecretd (PID 978) in the prior boot likely caused kwalletd6’s D-Bus errors, such as:
    • g_dbus_proxy_get_object_path: assertion ‘G_IS_DBUS_PROXY (proxy)’ failed
    • qt.dbus.integration: QDBusConnection: name ‘org.kde.secretservicecompat’ had owner ‘’ but we thought it was ‘:1.37’
  • These errors appeared in the current boot (10:02:20) despite ksecretd (PID 967) running, indicating ongoing D-Bus synchronization issues.
  • kwalletd6’s log of Secret Service availability changed: Available suggests it recovered, but non-KDE apps may still be affected.
8

I filed a bug report:

https://bugs.kde.org/show_bug.cgi?id=504539

1 Like
9

So every time i have this crash, kde’s own crash process viewer mentions always the same components which are not really kwallet related.

PID: 971 (ksecretd)
UID: 1000 (turker)
GID: 1000 (turker)
Signal: 11 (SEGV)
Timestamp: Tue 2025-05-20 12:17:21 +03 (3h 44min ago)
Command Line: /usr/bin/ksecretd
Executable: /usr/bin/ksecretd
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-dbus\x2d:1.1\x2dorg.kde.secretservicecompat.slice/dbus-:1.1-org.kde.secretservicecompat@0.service
Unit: user@1000.service
User Unit: dbus-:1.1-org.kde.secretservicecompat@0.service
Slice: user-1000.slice
Owner UID: 1000 (turker)
Boot ID: c93b5ee8676c46f08f2d8eded101e897
Machine ID: eeb883be3dd04481afc996d30d7ef30b
Hostname: 0000
Storage: /var/lib/systemd/coredump/core.ksecretd.1000.c93b5ee8676c46f08f2d8eded101e897.971.1747732641000000.zst (present)
Size on Disk: 3.9M
Message: Process 971 (ksecretd) of user 1000 dumped core.

            Stack trace of thread 971:
            #0  0x0000ffff57c270f8 n/a (libc.so.6 + 0x870f8)
            #1  0x0000ffff57bd6f9c raise (libc.so.6 + 0x36f9c)
            #2  0x0000ffff59f04d24 _ZN6KCrash19defaultCrashHandlerEi (libKF6Crash.so.6 + 0x4d24)
            #3  0x0000ffff5a488828 n/a (ld-linux-aarch64.so.1 + 0x38828)
            #4  0x0000ffff5a488828 n/a (ld-linux-aarch64.so.1 + 0x38828)
            #5  0x0000ffff59de7e78 _ZN3QCA12MemoryRegionD1Ev (libqca-qt6.so.2 + 0x77e78)
            #6  0x0000ffff57c36fac n/a (libc.so.6 + 0x96fac)
            #7  0x0000ffffeb623e50 n/a (n/a + 0x0)
            ELF object binary architecture: AARCH64

You see that they are “libc.so.6 and libqca-qt6.so.2”. These are in all the crash reports for the ksecretd crash that happens during boot. Any clue?

PS: KDE devs told me that there is nothing they could do about this and i can ignore the crash, as the service continues to run without issues after that.