Bug 186724 - Password dialogs consume 100% CPU and drop input
Summary: Password dialogs consume 100% CPU and drop input
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
: 230109 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-03-10 05:46 UTC by David
Modified: 2010-03-09 22:59 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
about 5 seconds of strace -p on the kdepasswd process (21.79 KB, application/x-gzip)
2009-03-10 05:48 UTC, David
Details
about 5 seconds of strace -p on the X process, when kdepassword is running (25.61 KB, application/x-gzip)
2009-03-10 05:49 UTC, David
Details
about 5 seconds of strace -p on the X process, when kdepassword is NOT running (for comparison) (5.51 KB, application/x-gzip)
2009-03-10 05:49 UTC, David
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David 2009-03-10 05:46:26 UTC
Version:            (using KDE 4.2.1)
Compiler:          gcc 4.3 
OS:                Linux
Installed from:    Fedora RPMs

Whenever a password dialog is displayed, e.g. from kwallet due to Kopete, or Kontact, or the networkmanager plasmoid, CPU usage jumps to 100%. Hitting keys on the keyboard causes *'s to show up in the password field, but sometimes they lag by up to several seconds, and sometimes keys will be completely dropped. This causes me to have to type my password character-by-character to make sure my keystrokes are accepted, or else it will drop some randomly and I'll have to enter it again.

Steps to reproduce:

1. Cause KDE to ask for a password (e.g. the screensaver lock, kwallet, or run kdepasswd).
2. Observe that CPU usage is at 100% (for me, 70% by X and about 17% by kded4 or kdepasswd or whatever's asking for the password). Also observe that *'s take a while to show up, and sometimes get dropped (i.e. it's as if you didn't type them).

Expected results:
CPU usage is low. Keyboard presses are accepted and show up on the screen instantly.

This happens on both my Dell Inspiron 1420 and Inspiron Mini 9. They are running Fedora 10 and SuSE 11.1, with KDE 4.2.1 from kde-redhat repository and OpenSUSE Factory. This was also present in KDE 4.2.0 on both machines. Both machines have Intel integrated graphics -- I think this is relevant. Both machines suffer from this bug identically.
Comment 1 David 2009-03-10 05:48:29 UTC
Created attachment 31970 [details]
about 5 seconds of strace -p on the kdepasswd process
Comment 2 David 2009-03-10 05:49:09 UTC
Created attachment 31971 [details]
about 5 seconds of strace -p on the X process, when kdepassword is running
Comment 3 David 2009-03-10 05:49:33 UTC
Created attachment 31972 [details]
about 5 seconds of strace -p on the X process, when kdepassword is NOT running (for comparison)
Comment 4 David 2009-03-10 05:53:51 UTC
I forgot to mention -- this does not happen with all password fields. Usually password fields that are displayed with non-password fields, as opposed to a dialog with just a password field, don't have this behavior. For example, if I try to add or edit a mail account in Kmail, at the screen where it asks host/port/login/password e.g. for POP3/IMAP connections, that password field works fine.
Comment 5 Arthur Schiwon 2009-03-31 00:04:17 UTC
I can confirm this on Kubuntu 9.04 (Beta)
Comment 6 Alexandre DENIS 2009-11-04 22:35:44 UTC
I confirm this bug, with KDE 4.3.2, from Debian Sid.

The problem actually appear only if you choose "three bullets for each letter" in system settings.

Steps to reproduce the bug:
-- launch System Settings, click "About me", choose "Show three bullets for each letter". Apply new settings.
-- launch Qt Designer, create an empty dialog
-- add a KRestrictedLine to the dialog
-- toggle the "password" property of the KRestrictedLine
-- CPU usage sudently jumps to 100%
Comment 7 David 2009-12-10 22:22:47 UTC
Alexandre: How you ever thought to check that setting is beyond me but I'm very glad I finally have a workaround. Thank you.

This issue is still present in KDE 4.3.3 from the Fedora 12 repository. With the latest ibus updates, password fields are now completely broken (i.e. no keyboard buttons, including enter/esc, work) when show three bullets is on.

https://bugzilla.redhat.com/show_bug.cgi?id=545266
Comment 8 Christoph Feck 2010-01-31 20:07:42 UTC
SVN commit 1083166 by cfeck:

Fix paint recursion in "three bullet" password mode

There are other issues related to "three bullet" mode, such as
not being able to move cursor or select text. But simple typing
and backspace should work without 100% CPU and hangs.

Please test if this commit fixes this bug, it will be available
with the KDE SC 4.4.0 release.

CCBUG: 180482
CCBUG: 186724
CCBUG: 211250
CCBUG: 215380
CCBUG: 224693


 M  +10 -0     klineedit.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1083166
Comment 9 Christoph Feck 2010-01-31 20:08:51 UTC
SVN commit 1083167 by cfeck:

Fix paint recursion in "three bullet" password mode (backport r1083166)

CCBUG: 180482
CCBUG: 186724
CCBUG: 211250
CCBUG: 215380
CCBUG: 224693


 M  +10 -0     klineedit.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1083167
Comment 10 Christoph Feck 2010-02-24 01:13:40 UTC
Assuming the bug is fixed, since there was no further feedback. Please reopen if you see this issue with KDE SC 4.4.x.
Comment 11 David 2010-02-25 21:14:09 UTC
Thanks, works for me on 4.4.
Comment 12 Christoph Feck 2010-03-09 22:59:25 UTC
*** Bug 230109 has been marked as a duplicate of this bug. ***