[Re-sending manually, as I think the first copy got lost. Apparently, bashbug and Postfix did not get along very well.]
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.
