This is the mail archive of the
mailing list for the GDB project.
Re: Spurious testsuite failures due to multibyte locale
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: gdb-patches at sources dot redhat dot com, schwab at suse dot de
- Date: Sun, 5 Jan 2003 11:28:51 -0600
- Subject: Re: Spurious testsuite failures due to multibyte locale
Andreas Schwab writes:
> I'm getting numerous spurious testsuite failures when running in a
> multibyte locale like utf8 because the version of readline included in
> gdb forces the command line to be always redrawn completely when
> running in a multibyte locale. The output of the prompt will look
> like "\r\n\r\r(gdb) \r(gdb) " which won't be matched by $gdb_prompt.
At first I thought it was an artifact of my test bed configuration, but
I've straightened out my test bed and it still happens. This is with
host=i686-pc-linux-gnu, osversion=red-hat-8.0, with $LANG=en_us.UTF-8.
I work around it now by setting $LANG=en_us when I run the test suite.
> -# Copyright 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000
> +# Copyright 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2003
As long as you are touching this line, can you add 2001 and 2002
to the copyright years? I checked "cvs log gdb.exp" and there
were plenty of changes during those two years.
> +# Make sure we are using the C locale.
> +set env(LC_ALL) "C"
Seems okay to me but I don't have the resources to test it right now.
I've appended my brain dump just in case anyone is curious.
It's on my TODO list to write a small "readline" test program and
file a bug report with the readline maintainers.
# 2002-12-13: readline 4.3 was imported into gdb HEAD last week.
# It causes perverse screen output: instead of "(gdb) print x",
# I see "(gdb) ^M(gdb) p^M(gdb) pr^M(gdb) pri^m..." with a
# carriage return for each character.
# This output style comes as a surprise to all the dejagnu
# patterns. The symptoms are massive timeouts starting in
# gdb.base/annota1.exp and continuing throughout the test suite.
# It looks like readline/display.c:_rl_move_cursor_relative
# has a multibyte bug (MB_CUR_MAX != 1 &&d rl_byte_oriented == 0).
# The first optimization "_rl_last_c_pos == new" is disabled
# because "_rl_last_c_pos" is a display position but "new"
# is an index in a a multibyte string, so they are not comparable.
# That is okay. But later on, this block appears:
# #if defined (HANDLE_MULTIBYTE)
# /* NEW points to the buffer point, but _rl_last_c_pos is the display point.
# The byte length of the string is probably bigger than the column width
# of the string, which means that if NEW == _rl_last_c_pos, then NEW's
# display point is less than _rl_last_c_pos. */
# else if (_rl_last_c_pos >= new)
# else if (_rl_last_c_pos > new)
# Not so fast, cowboy! _rl_last_c_pos == new here, but all the
# characters are plain, so they might match just fine. But readline
# pessimizes out and issues a CR and reprints the line every time.
# There should be logic here to compare the strings rather than just
# assume that a left-move is needed.
# To work around this, I just change $LANG. The default $LANG
# on my installation of red hat linux 8 is "en_US.UTF-8".
# Just plain "en_US" appears to work.