Bug 74266 - command history "browsing" may result in session closing
command history "browsing" may result in session closing
Product: Red Hat Linux Beta
Classification: Retired
Component: bash (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2002-09-19 01:16 EDT by Thomas M Steenholdt
Modified: 2007-04-18 12:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-09-29 03:19:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
traceback of bash crash (1.50 KB, text/plain)
2002-11-05 16:49 EST, Guðmundur D. H.
no flags Details
failing i18n configuration (91 bytes, text/plain)
2003-09-17 15:51 EDT, Thomas M Steenholdt
no flags Details
the file contains a string that, put on the command line, will trigger the problem (35 bytes, text/plain)
2003-09-17 15:54 EDT, Thomas M Steenholdt
no flags Details
stack trace of the crash (71.06 KB, text/plain)
2003-09-17 15:57 EDT, Thomas M Steenholdt
no flags Details
different kind of misbehaviour (non-crash) caused by international chars (142.17 KB, text/plain)
2003-09-17 16:02 EDT, Thomas M Steenholdt
no flags Details

  None (edit)
Description Thomas M Steenholdt 2002-09-19 01:16:36 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826

Description of problem:
I've noticed this a few times on several machines, that sometimes using the
up-arrow to select a command from history (usually more than one hit on the key)
the session are suddenly closed. I can't remember seeing this when logged in as
other than root, but I have seen it in gnome-terminal and normal tty, when
logged in as root or when logged in as user and su - 'ed to root

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

How reproducible:

Steps to Reproduce:
1. ctrl + alt + 1 (select tty1)
2. login as root
3. hold down the up-arrow on the keyboard and wait for the session to terminate

Actual Results:  The session just terminates

Expected Results:  The session should not terminate

Additional info:

I've searched in /var/log/messages - nothing there except the the session was
Comment 1 Tim Waugh 2002-10-07 09:37:28 EDT
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?
Comment 2 Thomas M Steenholdt 2002-10-08 02:00:56 EDT
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!
Comment 3 Tim Waugh 2002-10-08 10:15:10 EDT
Please re-open if it happens again.
Comment 4 Thomas M Steenholdt 2002-10-18 03:03:09 EDT
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
Comment 5 Thomas M Steenholdt 2002-10-18 03:06:11 EDT
Oh, and it DOES happen on 8.0 final - the latest scenario is from such a system!
Comment 6 Thomas M Steenholdt 2002-11-05 08:59:03 EST
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
Comment 7 Guðmundur D. H. 2002-11-05 16:49:36 EST
Created attachment 83764 [details]
traceback of bash crash
Comment 8 Guðmundur D. H. 2002-11-05 16:51:31 EST
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! :)

Comment 9 Mike A. Harris 2002-11-08 11:38:07 EST
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
[mharris@devel mharris]$ echo C6C$C<
[mharris@devel mharris]$ echo C6Connection to devel closed.
pts/12 mharris@zod:~$
Comment 10 Mike A. Harris 2002-11-08 11:44:58 EST
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.
Comment 11 Mike A. Harris 2002-11-08 11:45:42 EST
Almost forgot...

[mharris@devel mharris]$ rpm -q readline
Comment 12 Tim Waugh 2002-11-08 11:51:56 EST
This is fixed in bash-2.05b-7, in rawhide.
Comment 13 Thomas M Steenholdt 2002-11-08 14:26:39 EST
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 :-)
Comment 14 Thomas M Steenholdt 2003-08-27 17:52:39 EDT
Moving up to Severn 9.0.93 + rawhide bash-2.05b-26.1

Problem appears again!!!
Comment 15 Thomas M Steenholdt 2003-09-05 15:24:27 EDT
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".
Comment 16 Thomas M Steenholdt 2003-09-05 15:27:10 EDT
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*
Comment 17 Tim Waugh 2003-09-17 09:24:25 EDT
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.
Comment 18 Thomas M Steenholdt 2003-09-17 15:51:23 EDT
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!
Comment 19 Thomas M Steenholdt 2003-09-17 15:54:23 EDT
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.
Comment 20 Thomas M Steenholdt 2003-09-17 15:57:20 EDT
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!
Comment 21 Thomas M Steenholdt 2003-09-17 16:02:33 EDT
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
Comment 22 Tim Waugh 2003-09-18 09:40:57 EDT
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. ;-)
Comment 23 Thomas M Steenholdt 2003-09-18 15:05:49 EDT
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!

Comment 24 Thomas M Steenholdt 2003-09-20 13:47:36 EDT
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???
Comment 25 Tim Waugh 2003-09-29 03:19:56 EDT
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.

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