bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Segfaults on long non-ASCII current directory in X terminal


From: fbriere
Subject: Segfaults on long non-ASCII current directory in X terminal
Date: Sun, 19 Feb 2017 16:50:59 -0500 (EST)

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -Wdate-time 
-D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-FZHZjH/bash-4.4=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -no-pie 
-Wno-parentheses -Wno-format-security
uname output: Linux fabul 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) 
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.4
Patch Level: 11
Release Status: release

Description:

[This was originally filed as https://bugs.debian.org/843819.]

Bash will segfault when the following two conditions are met:

 - A long current directory pathname, including at least one non-ASCII
   character (and $LANG set appropriately)

 - The presence of "\w" in $PS1, both by itself and within a Set Text
   Parameters terminal control sequence (which seems to be the default
   for Debian)

(The latter probably implies an X terminal; I wasn't able to trigger
this bug in a virtual terminal.  For the record, I've had success
triggering it with both xterm and xfce4-terminal, while the original
submitter used gnome-terminal.)


Steps to reproduce (adjust $LANG if need be):

  $ export PS1='\[\e]0;\w\a\]\w\$ '
  $ export LANG="en_US.UTF-8"
  $ mkdir -p là/`perl -e 'print "X" x 255'`
  $ cd là/X*
  Segmentation fault (core dumped)

(The required length apparently depends on the terminal size; you may
need to shrink the window or add more directory components if this
doesn't segfault right away.)


After playing with gdb a little bit, it seems the problem occurs within
the while() at lib/readline/display.c:763.  At some point, num and n0
get stuck to the same value, _rl_col_width() at line 828 therefore
returns 0, and lpos is decreased by a *negative* value.  The loop has
now become infinite, and newlines will eventually grow beyond the
allocated size for inv_lbreaks[].

(I have attached a full backtrace with -O0 to the Debian bug report,
which I will omit here due to its size.)


Let me know if there's anything I can do to help.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]