Bug 72122 - en_GB.UTF-8 and en_US.UTF-8 locale lock up everything
en_GB.UTF-8 and en_US.UTF-8 locale lock up everything
Product: Red Hat Public Beta
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2002-08-21 05:04 EDT by Michael Schwendt
Modified: 2016-11-24 07:25 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-22 04:07:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Schwendt 2002-08-21 05:04:11 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020809

Description of problem:

# xterm -e su -
# cat /etc/sysconfig/i18n 
# export LANG="en_GB.UTF-8"
# up2date

At this point, CPU usage rises near 100%, stays there, and up2date does not
start. Upon pressing CTRL+C, I can break free from this, but "root" can no
longer access the filesystem. Simple operations like "ls" or "ll /var/lib/rpm"
hang with 100% and must be interrupted with CTRL+C. Exiting xterm and opening a
new one is a work-around.

The same with ordinary users instead of "root". It then does not even display
the consolehelper root password prompt dialog.

Version-Release number of selected component (if applicable):

How reproducible:

Additional info:

No such problem with the current default de_DE.UTF-8 locale here. Only when I
override the LANG environment variable to either en_GB.UTF-8 or en_US.UTF-8.
Comment 1 Adrian Likins 2002-08-21 14:55:13 EDT
whats using all the cpu? up2date or something else (console helper?)

Could be a glibc issue. Do other apps work with this locale
set this way?

Does up2date work with other locales?
Comment 2 Michael Schwendt 2002-08-21 15:24:53 EDT
> whats using all the cpu?


> Do other apps work with this locale set this way?

D'oh! No. :-O

For instance, "export LANG="en_GB.UTF-8" ; pine" hangs similarly. "ls" hangs,
"logout" hangs, everything hangs. *Sorry*, I've been test-driving the German
default locale with (null) primarily. Component change to "glibc".

> Does up2date work with other locales?

In addition to "Additional comment" of the bug report:

C           : YES
en_GB.UTF-8 : NO
en_GB       : YES
en          : YES => Using the fallback 'C' locale.
en_US.UTF-8 : NO
en_US       : YES
de_DE.UTF-8 : YES
de_DE       : YES
de          : YES => Using the fallback 'C' locale.
Comment 3 Michael Schwendt 2002-08-21 16:34:58 EDT
Changed summary from [up2date] "hangs and locks fs access with en_GB.UTF-8
locale" to [glibc] "en_GB.UTF-8 and en_US.UTF-8 locale lock up everything".

glibc and glibc-common packages verify fine. kernels tried: 2.4.18-11.i686 from
(null) and 2.4.18-12.athlon from Raw Hide.

Actually, when I change the default locale in /etc/sysconfig/i18n to en_GB.UTF-8
(British English has been my default locale so far with Valhalla and older), I
cannot even log in anymore (have had to rescue the system).

de_DE.UTF-8 seems to work flawlessly (but I don't like that German locale).

I can't believe this. If I had installed (null) with en_GB.UTF-8 as default
locale as with Limbo and Limbo beta2, would that have worked?
Comment 4 Bill Nottingham 2002-08-21 23:42:01 EDT
Are you using glibc-2.2.90-24? If so, what happens if you try a different glibc?
Comment 5 Jakub Jelinek 2002-08-22 03:27:10 EDT
This is a known bug http://sources.redhat.com/ml/libc-hacker/2002-08/msg00118.html
I'll build a fixed glibc today.
As workaround, you can export LOCPATH=/usr/lib/locale
and it will work...
Comment 6 Michael Schwendt 2002-08-22 04:07:23 EDT
Yes, glibc-2.2.90-24.

With the proposed work-around (de_DE.UTF-8 works!), I see this:

$ export LOCPATH=/usr/lib/locale
$ export LANG="en_GB.UTF-8"
$ up2date

still hangs, CPU usage around 94% now for "/usr/sbin/userhelper -w up2date".
Other programs work with this work-around, though.
Comment 7 Michael Schwendt 2002-08-30 15:45:00 EDT
glibc-2.2.90-26 from (null) 7.3.95-0.20020827 updates fixes this for me.

Note You need to log in before you can comment on or make changes to this bug.