From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22984 invoked by alias); 5 Jan 2003 17:29:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22973 invoked from network); 5 Jan 2003 17:29:03 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 209.249.29.67 with SMTP; 5 Jan 2003 17:29:03 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h05HSp119547; Sun, 5 Jan 2003 11:28:51 -0600 Date: Sun, 05 Jan 2003 17:29:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200301051728.h05HSp119547@duracef.shout.net> To: gdb-patches@sources.redhat.com, schwab@suse.de Subject: Re: Spurious testsuite failures due to multibyte locale X-SW-Source: 2003-01/txt/msg00187.txt.bz2 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. Me too: http://sources.redhat.com/ml/gdb-patches/2002-12/msg00294.html 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. Michael C === # 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 # else if (_rl_last_c_pos > new) # #endif # # 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.