Cannot open terminal with long working directory name containing Unicode characters

[Simon May]

1) The release of Ubuntu you are using: Ubuntu 17.10

2) The version of the package you are using: gnome-terminal version 3.24.2-0ubuntu4; bash version 4.4-5ubuntu1

3) What you expected to happen: When opening a terminal window with a long working directory path containing Unicode characters (such as “/home/test/01234567890123456789/01234567890123456789/ä/01234567890123456789/01234567890123456789/01234567890123456789/01234567890123456789” in a 80×24 window), gnome-terminal opens normally.

4) What happened instead: gnome-terminal closes immediately, both when opened using
gnome-terminal --working-directory=/home/test/01234567890123456789/01234567890123456789/ä/01234567890123456789/01234567890123456789/01234567890123456789/01234567890123456789
and when changing to this directory using “cd”. There is no output on stderr or anywhere else, the window just closes.

It seems that gnome-terminal closes because bash crashes with a segmentation fault, see https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1745273/comments/4.

This makes it impossible to use the shell for many directories with long paths. This did NOT happen in Ubuntu 16.04.

[Egmont Koblinger (egmont-gmail)]

Hi,

What happens when you "cd" to that directory in another terminal emulator, such as xterm?

[Egmont Koblinger (egmont-gmail)]

Is that "ä" a precomposed character, or an "a" followed by a combining accent? Execute this command to find it out:

ls /home/test/01234567890123456789/01234567890123456789 | od -t x1

I'm wondering if you might be hitting this bash bug:
http://lists.gnu.org/archive/html/bug-bash/2017-11/msg00075.html

[Simon May (socob)]

When I change to that same directory in xterm, it closes just like gnome-terminal. So it doesn’t seem to be specific to gnome-terminal, but it DOES seem to be important that the input prompt fills more than two lines in the terminal to trigger the bug.

I’ve tested this on my laptop, and it doesn’t happen there with the path from the original report because this machine’s hostname is shorter, so the input prompt is shorter as well. Using an even longer path, however, the same happens on this machine.

The “ä” is a precomposed character. Using your command, the output is
0000000 c3 a4 0a
0000005
c3 a4 is the UTF-8 representation of the Unicode character U+00E4 LATIN SMALL LETTER A WITH DIAERESIS. So I’m not sure if that specific bash bug has anything to do with this (since there are no surrogates anywhere in my example), but since xterm is also affected, the cause does seem to be a lower-level component (bash? readline?).

[Simon May (socob)]

As a quick update, it does seem to be bash that crashes – see the following terminal session:

user@host:~$ sh
$ cd /home/test/01234567890123456789/01234567890123456789/ä/01234567890123456789/01234567890123456789/01234567890123456789/01234567890123456789/01234567890123456789/
$ bash
Segmentation fault (core dumped)
$

At this point, no more terminal input is possible.

[Egmont Koblinger (egmont-gmail)]

Hi,

The bash bug I linked indeed seems to be a different one; however, it might give some clues about what might going on. E.g. your locale, PS1, PROMPT_COMMAND etc. _might_ be relevant. (I cannot reproduce your problem, although I can see the prompt incorrectly showing parts of color changing escape sequences. I have a custom PS1, though. Allegedly work-in-progress bash-4.5 is going to contain yet another bunch of related fixes.)

Could you try for example to “unset PROMPT_COMMAND” at the last line of your .bashrc, or change to a much simpler PS1, does it still crash then?

Could you please try with bash development version?

git clone https://git.savannah.gnu.org/git/bash.git
cd bash
git checkout devel
./configure
make DEBUG= MALLOC_DEBUG=
./bash

If this one is still buggy, it would the best if you could raise this issue with upstream bash maintainers. There's a "bashbug" tool that collects the information required by developers. (Since I don't have cmdline email sending set up, I just see which file it opens for me to edit, open the same file in gedit and copy-paste to my favorite email client (this way long lines don't get chopped).)

If the devel version is okay then Ubuntu will also be fixed whenever bash-4.5 is released and then Ubuntu upgrades to that, which might still take quite a while. I'm sorry but I won't be able to help backporting the fix to Ubuntu, I'm not an Ubuntu developer, just lurking around here keeping an eye on gnome-terminal :)

[Simon May (socob)]

My locale is as follows:
$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=

Using “unset PROMPT_COMMAND” had no effect at all (and seems to be empty for me, anyway?). This is pretty much a fresh install, so I’m using Ubuntu’s default value of PS1:

$ echo "'$PS1'"
'\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '

However, when I change that to

PS1='\[\033[01;34m\]\w\[\033[00m\]\$ '

there seems to be no more crashing. So it seems that certain values of PS1 do indeed trigger this bug.

I have also tried the bash development version, as suggested. Even with the default value of PS1, I haven’t been able to cause a crash there. However, this version goes REALLY crazy with the input prompt (junk characters, erratically printing parts of the history or working directory path to the terminal when pressing the arrow keys, invisible text input etc.) for long working directory paths (with or without Unicode characters), making input all but impossible. So whatever the difference between the two versions is, it’s not an improvement.

Anyway, thanks a lot for the help so far. Since I’m not seeing the crash in the newer version, I’m assuming it will be gone when Ubuntu updates (with the weird behavior for long paths hopefully due to different compiler flags or something like that). As a workaround, modifying PS1 seems to work.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Kieran Grant (kieran-grant)]

Possibly what I encountered and reported to BASH (with my other email address)
Apply this patch https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-019
Or try building from git, bash 4.4.19.
I'll quote report description:
"With certain values for PS1, especially those that wrap onto three or more
lines, readline will miscalculate the number of invisible characters,
leading to crashes and core dumps."

[Egmont Koblinger (egmont-gmail)]

18.04 Bionic, to be released tomorrow, ships bash-4.4.19. So if Kieran's guess is correct then it should no longer crash there; Simon could you please check this once you upgrade your system?

[Simon May (socob)]

Indeed, it seems to be gone/fixed in 18.04.

[Simon May (socob)]

Fixed in Ubuntu 18.04

[Simon May (socob)]

Caused by a bash bug/crash