Bug 77455 - User Account module freezes after changung real name
Summary: User Account module freezes after changung real name
Status: RESOLVED WORKSFORME
Alias: None
Product: kcontrol
Classification: Miscellaneous
Component: kcmuserinfo (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Ravikiran Rajagopal
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-13 12:26 UTC by Jure Repinc
Modified: 2008-04-06 23:22 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jure Repinc 2004-03-13 12:26:41 UTC
Version:            (using KDE KDE 3.2.0)
Installed from:    Gentoo Packages
Compiler:          gcc (GCC) 3.3.3 20040217 
OS:          Linux

Steps to reproduce
1. Click Preferences button in Kicker > System Administration > User Account
2. Click Change Real Name
3. Enter new name and password
4. Click OK

Result
User Account interface doesn't redraw itself anymore and it starts using a lot of CPU. After you kill and restart the username is changed correctly

Expected result
User Account should change the name and continue normaly.

This is what I got from GDB after attaching to process and typing where:
#0  0x0000002a979e5bd7 in fcntl () from /lib/libpthread.so.0
#1  0x0000002a960b2765 in PtyProcess::readLine(bool) ()
   from /usr/kde/3.2/lib/libkdesu.so.4
#2  0x0000002a9b70a0c0 in ChfnProcess::ConverseChfn(char const*) ()
   from /usr/kde/3.2/lib/kde3/kcm_userinfo.so
#3  0x0000002a9b709fc8 in ChfnProcess::exec(char const*, char const*) ()
   from /usr/kde/3.2/lib/kde3/kcm_userinfo.so
#4  0x0000002a9b7056b3 in KUserInfoConfig::slotChangeRealName() ()
   from /usr/kde/3.2/lib/kde3/kcm_userinfo.so
#5  0x0000002a9b708093 in KUserInfoConfig::qt_invoke(int, QUObject*) ()
   from /usr/kde/3.2/lib/kde3/kcm_userinfo.so
#6  0x0000002a96dd33c3 in QObject::activate_signal(QConnectionList*, QUObject*)
    () from /usr/qt/3/lib/libqt-mt.so.3
#7  0x0000002a96dd321c in QObject::activate_signal(int) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#8  0x0000002a97081137 in QButton::clicked() ()
   from /usr/qt/3/lib/libqt-mt.so.3
#9  0x0000002a96e4f784 in QButton::mouseReleaseEvent(QMouseEvent*) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#10 0x0000002a96e00855 in QWidget::event(QEvent*) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#11 0x0000002a96d833a2 in QApplication::internalNotify(QObject*, QEvent*) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#12 0x0000002a96d82b58 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#13 0x0000002a962842d8 in KApplication::notify(QObject*, QEvent*) ()
   from /usr/kde/3.2/lib/libkdecore.so.4
#14 0x0000002a96d28935 in QETWidget::translateMouseEvent(_XEvent const*) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#15 0x0000002a96d267dd in QApplication::x11ProcessEvent(_XEvent*) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#16 0x0000002a96d3a348 in QEventLoop::processEvents(unsigned) ()
   from /usr/qt/3/lib/libqt-mt.so.3
#17 0x0000002a96d93d64 in QEventLoop::enterLoop() ()
   from /usr/qt/3/lib/libqt-mt.so.3
#18 0x0000002a96d83585 in QApplication::enter_loop() ()
   from /usr/qt/3/lib/libqt-mt.so.3
#19 0x0000002a96f1b9ca in QDialog::exec() () from /usr/qt/3/lib/libqt-mt.so.3
#20 0x0000002a9976a542 in kdemain ()
   from /usr/kde/3.2/lib/libkdeinit_kcmshell.so
#21 0x0000002a99650ac9 in kdeinitmain () from /usr/kde/3.2/lib/kde3/kcmshell.so
#22 0x0000000000405cb9 in ?? ()
#23 0x0000000000406eea in ?? ()
#24 0x0000000000407484 in ?? ()
#25 0x00000000004082b2 in ?? ()
#26 0x0000002a9841d8b1 in __libc_start_main () from /lib/libc.so.6
#27 0x00000000004046ea in ?? ()
Comment 1 Michał Kosmulski 2004-05-07 10:07:56 UTC
I confirm this behavior for kde 3.2.1 but only when the real name entered contains non-ascii characters. The module seems to fall into an infinite loop with 100% CPU usage. However, for my name (Michał Kosmulski), after killing the program, the name is not changed correctly, but gets a '?' in place of the 'ł'.
The command line tool for the same job (chfn) rejects 'ł' in real name although its man page says it will accept anything not containing control characters, ':' and a few other chars used commonly as separators. As far as I know, UTF-8 encoded chars never use anything in ascii range 0-127 (except for encoding these very ascii chars), so I don't know why chfn is complaining. When I manually edit my /etc/passwd and enter a UTF-8 encoded 'Michał Kosmulski', everything seems to work OK (and I get a nice description in KDM).
Comment 2 Lukáš Tinkl 2005-01-16 13:19:02 UTC
Works fine in KDE 3.4 beta1
Comment 3 Martin Koller 2005-01-21 23:30:31 UTC
I have this problem with HEAD from 20.Jan.2005 when I work as root user (I did not test it with non-root user).
The Name I entered has no special chars in in (it was "Martin Koller xxx" as a test)

The bt from within gdb was:

(gdb) bt
#0  0x413b9fdc in do_fcntl () from /lib/libpthread.so.0
#1  0x413ba25f in fcntl () from /lib/libpthread.so.0
#2  0x4068ac8e in PtyProcess::readLine (this=0xbfffe518, block=true) at 
process.cpp:186
#3  0x41c601dd in ChfnProcess::ConverseChfn (this=0x82f4b78, pass=0x82a8210 
"********") at qcstring.h:249
#4  0x41c600ba in ChfnProcess::exec (this=0x82f4b78, pass=0x82a8210 
"********", name=0x828cb28 "Martin Koller xxx")
    at chfnprocess.cpp:40
#5  0x41c6277d in KCMUserAccount::save (this=0x82e1930) at qcstring.h:291
<snip>
Comment 4 Philip Rodrigues 2007-03-08 23:35:24 UTC
Does this problem still occur with KDE 3.5?
Comment 5 Philip Rodrigues 2007-04-30 23:01:02 UTC
Feedback timeout, but please reopen if the problem still occurs in KDE 3.5. Thanks!
Comment 6 Nicolas L. 2008-04-06 23:14:59 UTC
please reopen, it appears that the freeze appear when you add special letters on the Name like é ë , ... where as is we use them directly with chfn, there is no problems
Comment 7 rapsys 2008-04-06 23:22:24 UTC
The problem is a bit more incidious...

I tried to understand what realy is passed to chfn.

But in fact it seems there is an excessive conversion from utf-8 to iso8859-15.

For example, set the name to :
Raphaël

Instead of pass the string in correct utf8 :
0x52,0x61,0x70,0x68,0x61,0xc3,0xab,0x6c
It pass the iso8859-15 equivalent string :
0x52,0x61,0x70,0x68,0x61,0xeb,0x6c

And then chfn is invoqued with binary char which seems it is unable to drop/handle...

The result is chfn keep stuck and kcontrol loop forever waiting for something...

kill -9 chfn process workaround the bug.