https://bugs.kde.org/show_bug.cgi?id=515646
--- Comment #3 from michaelk83 <[email protected]> --- (In reply to Roke Julian Lockhart Beedell from comment #2) > Created attachment 189346 [details] > A Konqi Trace Of An Earlier Reproduction, On A Different Device > > Apologies. After the initial “File” → “New Wallet”, I didn't consider that > the traces might differ. To specify, “File” → “New Wallet” (then, choosing a > name) causes this, without needing to cancel the operation. Ok, the new trace shows its stuck in `KWalletManager::createWallet` -> `openWallet`, as expected. However: > I have attached a screencast at > https://bugs.kde.org/show_bug.cgi?id=514189#c2, > too, in case my examples are not clear. Once you see the "An error occurred when connecting to KWallet service" message inside KWalletManager, you're already in a faulty state. KWalletManager won't be able to do anything from that state, and ideally its menu should be disabled. This is just an expected secondary symptom. The underlying problem once you get that message, is that one of the background daemons ksecretd or kwalletd are already ANR themselves. I actually don't think this is the same as bug 514189. There, the abortion of the create process is what causes the daemon to ANR, here you're already starting from ANR. The question is, how did you get to that initial state with the "error connecting" message. Do you have steps to reproduce that initial error message? A backtrace of ksecretd and kwalletd in that state may also be helpful. It's probably not very useful to post more bugs to ReadHat on this, because this looks like an internal bug in KWallet, which would be upstream from ReadHat. -- You are receiving this mail because: You are watching all bug changes.
