https://bugs.kde.org/show_bug.cgi?id=522307
--- Comment #4 from [email protected] --- Thanks for looking into this! 1. kwalletd6 is stable — confirmed via `ps -o pid,etime,cmd`, the process has been running continuously (4+ minutes uptime at time of capture, matching session length) with no crashes/restarts. journalctl shows zero crash/core/segfault entries for kwalletd6. 2-3. I captured a full dbus-monitor trace (including replies, plus org.kde.KWallet and direct traffic to/from kwalletd6's two D-Bus connections). It's quite large (~5M lines) — happy to extract and attach a relevant excerpt if you can point me at what to grep for. For context: the same capture contains 17253 ReadAlias calls and 17254 CreateItem calls — almost exactly 1:1, suggesting kwalletd6 is calling ReadAlias and CreateItem together as a pair, repeatedly, rather than these being two unrelated polling loops. 4. I took 5 gdb backtrace samples of the live kwalletd6 process while the CPU loop was active (2s apart). I don't have app-level debug symbols resolved yet (working on that), but interestingly, 3 out of 5 samples show the main thread NOT in defaultCollection()/ReadAlias, but instead in: secret_item_create_sync () secret_service_create_item_dbus_path_sync () i.e. libsecret's CreateItem path, not ReadAlias. This might mean kwalletd6 is repeatedly creating a new secret item (possibly related to the kdewallet_attributes.json growth I noticed earlier in this investigation, which grows by one entry-cycle on each write), rather than just polling ReadAlias in isolation — or both might be part of the same retry cycle. I'm attaching the raw backtrace samples as-is; will follow up with resolved symbols (debuginfod or debuginfo packages) if that would help narrow it down further. Full backtrace samples attached. -- You are receiving this mail because: You are watching all bug changes.
