https://bugs.kde.org/show_bug.cgi?id=522615
michaelk83 <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Ever confirmed|0 |1 Status|REPORTED |CONFIRMED --- Comment #9 from michaelk83 <[email protected]> --- (In reply to Tomasz C. from comment #8) > The trigger turned out to be gnome-keyring-daemon owning the > org.freedesktop.secrets D-Bus name. Once it was > out of the picture, the leak stopped and has not returned. Good find! > gnome-keyring returns a Prompt object path but never creates the object: > Unlock -> object path "/org/freedesktop/secrets/prompt/u1" The spec doesn't explicitly specify prompt paths (another part where it's incomplete), but I suspect it should have been a numeric ID: `.../1`, `.../2`, etc. But `/org/freedesktop/secrets/prompt` being empty is also wrong, I think. https://specifications.freedesktop.org/secret-service/latest/object-paths.html Regardles of KDE's side, this is worth reporting to GNOME Keyring, as this looks like a bug on their end, and possibly a regression. > WHY THIS ONLY SURFACED NOW > Symptoms appeared only after KWallet moved to the kwalletd6 + ksecretd split That split was done over a year ago, in KDE Frameworks 6.14. Yet the memory leak reports only appeared about a month ago. I can think of two possible reasons: 1. A recent regression in GNOME Keyring breaking their prompt creation. 2. A recent regression in kwalletd causing it to use the public org.freedesktop.secrets interface instead of its internal org.kde.secretservicecompat interface. Normally, kwalletd uses the internal interface to talk to ksecrted, unless ksecrted is explicitly disabled in kwalletrc. > WHAT DID NOT HELP > apiEnabled=false in kwalletrc That simply disables the public API in ksecretd (leaving only its internal address). > Regardless, a guard on the kwalletd6 side seems worth considering -- a > timeout or > a retry limit while waiting for Completed -- so that a broken Secret Service > implementation on the other end cannot cause unbounded memory growth. I think the key fix on kwalletd side is to make sure it's using its internal address as intended. But I agree that guarding the waits is also desirable. -- You are receiving this mail because: You are watching all bug changes.
