One more glibc (or bash?) test

Alexander E. Patrakov semzx at
Sun Mar 14 07:51:56 PST 2004

I have glibc-2.3.3-20031204 with NPTL, but NPTL is irrelevant here. Other

ncurses 5.4 compiled with --enable-widec, according to my UTF-8 hint

readline 4.3 installed into /lib, linked against the wide-character version
of ncurses library; all patches from are applied

bash 2.05b linked against shared libreadline; all patches from are


I probably found an endless loop in glibc charset conversion code (or in
bash?) and I want to see if it is really so. Since I don't have a
by-the-book LFS-5.1pre installation, I hope you will help me to test this
bug on your by-the-book installation.

To reproduce:

1) Create the ru_RU.UTF-8 locale:

localedef -c -i ru_RU -f UTF-8 ru_RU.UTF-8

2) Start an UTF-8-enabled xterm:

(unset all  locale variables)
LC_ALL=ru_RU.UTF-8 xterm

3) In this xterm, type:

grep major /lib/modules/`uname -r`/mod

(type backtics exactly as shown, don't press Enter)

4) Press Tab to get the continuation - the bash process will eat 100% of the
CPU spinning in mbrtowc(), unclosed_pair(), __gconv_get_alias_db() and
similar functions.

Do you get this bug?

Alexander E. Patrakov

More information about the lfs-support mailing list