Bug 74266

Does this still happen in Red Hat Linux 8.0?  I can't reproduce it here. 
 
If it still happens, can you try attaching gdb to bash from another session 
(use 'gdb /bin/bash <pid>'), and use 'continue' to let it carry on running, 
and then try to reproduce the problem again?

Actually I have not seen the problem on 8.0 final, although that might be a
coincidence as I could not always possitively reproduce on freshly installed
machine. Also it could be that something simply changed from the betas to the
final version that somehow fixed the bug?!? 

I'm running 4 RH8.0 systems atm and I have not seen the problem once!

Please re-open if it happens again.

OK - This has to do with international chars like the danish 'f', 'x' and 'e' in
my situation... using these chars on the command line seems to be the source of
all kinds of problems...
I cannot easily reproduce the session crash( i did it a couple of times, but
really don't know the exact combination that triggers it ) but I can eat the
prompt, garble the command string so that nothing really makes sense in the line...
Try opening a tty and login as root
type a command containing the danish chars f,x or e - then before even hitting
enter, use the <- and -> arrows to move the cursor across the command ant you
will see strange things...

I believe that this is also the cause of the session crash - when some of the
garbled chars is put in the .bash_history the somehow, sometimes trigger the
session crash(or simply logout???) however it's always in a situation where some
 danish chars has been on the line, that i'm currently browsing the history to
using the up and down arrows...

Hope this somehow helps you to reproduce the problem on your end

Oh, and it DOES happen on 8.0 final - the latest scenario is from such a system!

actually this whole thing is quite annoying, though not exactly this
bug-repport, hitting the = key and trying to do something useful with that
command-line afterwards is quite impossible...

I frequently hit the tab button and hit the = instead when using the filename
autocompletion feature of the bash prompt, but once the = key has been hit, i
can't simply backspace the char and continue, as some leftovers of that
keystroke seems to be left in the actual command string... messing around with
such a line, trying to insert = in the middle of a string and deleting it again
has showed me this error message a couple of times:
ls: install.log: Invalid or incomplete multibyte or wide character

this bug does to some extend result in a less effective working environment

Created attachment 83764 [details]
traceback of bash crash

I and a friend have been able to reproduce this bug in this way:
(You'll have to have icelandic locale to do this :)

Log into RH8 machine, type and execute 'locate ~aettir', then after it has
executed, push the up arrow  button to get the command again, get the pointer at
~ae .. and push -

This was enough to crash bash

I've compiled and tested this on vanilla bash (no patches or anything), and it
still crashed. Backtrace is attached.

Should I include something else, or anything, just give me a line! :)

-G.

Wowsers.  I reproduced this pretty easy...  bugzilla totally slaughters
UTF-8 and other 8bit encodings so the below cut and paste wont be
accurate to what I typed...

[mharris@devel mharris]$ rpm -q bash
bash-2.05b-5
[mharris@devel mharris]$ echo C6C$C<
C6C$C<
[mharris@devel mharris]$ echo C6Connection to devel closed.
pts/12 mharris@zod:~$

The C6C$ garbage was 3 random UTF-8 characters in position 0x80 - 0xFF
of the unicode charmap space.  I typed the echo line, then it echoed
properly.  Then I pressed up-arrow, and left arrow'd over 4 times.  I
pressed backspace, and was immediately disconnected with the above.

Here is a backtrace of the crash:

Program received signal SIGSEGV, Segmentation fault.
0x080bd676 in _rl_get_char_len ()
(gdb) bt
#0  0x080bd676 in _rl_get_char_len ()
#1  0x080bd6e6 in _rl_compare_chars ()
#2  0x080b4032 in rl_redisplay ()
#3  0x080b2a6a in rl_redisplay ()
#4  0x080a8a5d in readline_internal_char ()
#5  0x080a8b35 in readline_internal_char ()
#6  0x080a8b60 in readline_internal_char ()
#7  0x080a870a in readline ()
#8  0x0805df75 in yy_input_name ()
#9  0x0805deec in yy_input_name ()
#10 0x0805e895 in read_secondary_line ()
#11 0x0805f40c in reset_parser ()
#12 0x0805ee64 in execute_prompt_command ()
#13 0x0805ddb3 in yyparse ()
#14 0x0805ccc4 in parse_command ()
#15 0x0805cd3f in read_command ()
#16 0x0805ca69 in reader_loop ()
#17 0x0805ae7b in main ()
#18 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

This looks like a bug in readline.

Almost forgot...

[mharris@devel mharris]$ rpm -q readline
readline-4.3-3

This is fixed in bash-2.05b-7, in rawhide.

fix confirmed at my place... reproducible crash stopped crashing the bash
session... typing special chars like = which used to break the current line
completely now doesn't... this must be one of the most important fixes for a
while now... at least a great deal of annoyance has disappeared from my life now :-)

Moving up to Severn 9.0.93 + rawhide bash-2.05b-26.1

Problem appears again!!!

Just realized that this happens on my Red Hat 9 system as well, but it appears
to happen only when I have LC_ALL="C" set.

I know LC_ALL is not set at all by default in Severn (at least not the way I
have been installing it) but if I don't set it, I will not be able to use dansih
national chars in OpenOffice... This is the first problem I have seen, as a
result of my setting LC_ALL="C".

Oh and it is easily reproducable too...

Set LC_ALL="C" in /etc/sysconfig/i18n
Boot system
Login to the console
type a line with a danish national char somewhere in the line, hit enter
use the up-arrow to select the same line again, then use the left-arrow to place
the cursor over one of the danish national chars and hit backspace *KAPOW*

I need more information to reproduce the problem.  It would help if you could be
more specific.

Could you please attach a file containing the exact line that you type in?

I think that you basically can't expect the C locale to deal with multibyte
input.  You need a character encoding such as UTF-8 or ISO-8859-1 to do that.

Created attachment 94562 [details]
failing i18n configuration

Just so that we are all in sync on this one. This is my i18n configuration file
that causes the problem to happen. The reason i put LC_ALL="C" in the file was
an initial attempt to make my danish chars work in Open Office... Bash works
just fine without the LC_ALL="C" setting and I admit, I really have no idea how
all the different internationalization setting are working on their own or
together with each other. It migh very well be the case that this SHOULD not
work, but it did work once!

Created attachment 94563 [details]
the file contains a string that, put on the command line, will trigger the problem

To trigger the problem, put the string, contained in the file, on a bash
command line and hit enter. Arrow up, to get the string back. Use the left
arrow to place the cursor over one of the danish chars, then hit backspace.
*POOF*

Created attachment 94564 [details]
stack trace of the crash

This is a pretty complete stack trace, from bash starts and until it crashes.
The method used to crash bash here is similar to the example outlined in the
comment i put together with the bad_command attachment.

Please let me know if you need me to make the trace in another way or format!

Created attachment 94565 [details]
different kind of misbehaviour (non-crash) caused by international chars

This is a stack trace of a different incarnation of the same problem.
Once the bad_command string is on the command-line, use the left- and right
arrow keys to move all the way to the beginning of the string and all the way
to the end of the string, over and over again. You'll notice that the beginning
of the string moves leftwards when doing this. The string moves left by as many
chars as there are danish national chars in the bad_command string, probably
because whatever strlen equiv. are used cannot determine the correct length of
the string due to the double byte chars.

Again, let me know if you need the trace in another way or format

Fixed in bash-2.05b-29.1.  Note that although the crash is fixed, you still
won't be able to edit multibyte character input properly in the C locale --
basically that's what real locale definitions are for. ;-)

Absolute coolness - I'll look around for some info on LC_ALL and LOCALE vars, to
see if i can figure out a proper way to not use LC_ALL="C" and still have a
working openoffice!

Thanks

The updated bash package fixes the crash alright... The other mentioned
behavioral problems are not fixed however... Using the national danish chars and
backspacing as long as you can(and further) will cause the prompt to be "eaten",
because it lets you backspace further than the actual command string length!

I've allowed myself to reopen the bug. I can create a new bugreport if you think
tha would be more useful???

As I mentioned before: the fix for that is to actually use the right locale. 
You can't use non-ASCII characters in an ASCII locale and just hope everything
will work, since it won't.