Running a non-existing command in the background causes exit

Sorry -- looking further I think this may be an issue with command_not_found_handler not gnome-terminal at all.

I confirm.

When you try using xterm - it behaves alike, however it more frequently works without crash - it prints new pid and after a while it prints bash: gdit: command not found. It does not return to prompt - you need to press enter and then it prints Exit 127.
Here:

 gdit &
[1] 6733
darek@spectrum:~$ bash: gdit: polecenie nieodnalezione

[1]+ Exit 127 gdit
darek@spectrum:~$ gdit &

I found that gnome-terminal works sometimes without crash - if you try run some non-existent commands without ampersand and then try it with ampersand it does not crash.

Maybe it is some buffer issue? And I have seen 'exit' in closing xterm.

Sort of to my surprise, I managed to reproduce this. I entered "does not exist &" at the bash prompt, and the shell exited. On opening a new Gnome terminal, I was quite surprised to find that that line made it into my bash history (which suggests it's a fairly clean exit). I had another succes with "pester the system &". As reported above, the shell exit does not occur every time.

I had a look at the bash code that handles this, but there's so much conditional forking and all... really way over my head for now.

As a guidance for setting the importance of this bug (to whomever is allowed to do that), I'd say it is of low importance. I just played around a bit in gdb, and the shell will refuse to exit when there are stopped jobs, so you won't lose work to this bug (as mentioned in my previous comment: you even keep your command history).

Attached is the console output of that playing around.

Sorry: clarification to the file just appended with the previous comment:
I didn't type the line that says "exit", it appears as a result of trying "cats &". This is the manifestation of the bug...

The same happends to me in Konsole (Kubuntu 10.4 alpha, Konsole 2.4.1, GNU bash version 4.1.0(1)-release)

This seems to not happen in later versions of Ubuntu. I guess it got patched.

I just ran into this bug and there seems to be a path-name dependency on it showing up. In some directories it happens consistently, making it a real annoyance. If it is in fact dependent on the length of a pathname, or the form of a directory name, that might be useful in locating the cause.

Here are the commands I used (my home directory is /home/wtz ):

cd ~
mkdir -p Projects
cd Projects
mkdir Foo
cd Foo
mkdir Test
cd Test
mkdir org
cd org
mkdir bzdev
cd bzdev
mkdir ejws
foo &
[crashes? - may be intermittent ]
cd ~/Projects
cd Foo
cd Test/org/bzdev
foo &
[error message ending with foo: command not found]
cd ~
cd Projects
cd Foo
cp -r Test Test-Test
cd Test-Test/org/bzdev
foo &
[gnome terminal disappears]

It acts like having the '-' in the directory name is related to the problem, but it could just be the path-name length, directory-name length, etc. In a subdirectory of a directory that has a '-' in the file name, the bug seems to always occur. I'm using a fairly recent version of Ubuntu (10.10) on a 2-core, Intel i3 with two threads per core.

Also, it seemed there was a dependency on whether the directory the command was run with had files or subdirectories in it (which needs to be verified, of course).

It seems this has reappeared after some absence. Don't know if bash is at fault. Anyway, in an xterm or gnome-terminal, typing

made_up_command &

Will often but not always cause the terminal to vanish which is extremely annoying!

I confirm the bug presence on Ubuntu Precise + some upstream packages.
bash version: 4.2-2ubuntu2.1
It is 100% repeatable and terribly annoying.
It is dependent on the path length. How to reproduce on my system:
1. Make sure that you have /usr/share/doc/texlive-doc/latex/computational-complexity, or whatever other long path, e.g., by installing texlive-science-doc version 2012.20120611-2.
2. Change into /usr/share/doc/texlive-doc/latex/computational-complexity.
3. Assuming some nonexistant command qqq, type
qqq &
into the bash shell and press Enter.
4. Observe that the bash closes. It should not.

Good catch. I confirm that path length does seem to be an issue here. This bug has been around since 2008 now -- it's very annoying.

The bug does not occur on Debian with
bash version 4.2+dfsg-0.1+deb7u3,
xterm version 278-4
and the de_DE.utf8 LANG and LC_... .
So, whoever has a chance to look for the error, take the diff...

I found out that though the bug is pretty reproducible on long path lengths, for short path lengths, the bug is sometimes reproducible, but sometimes not.
Test case:
1. Open an xterm with a bash.
2. Make sure that the command q is not present on your system.
3. cd / [Enter]
4. q & [Enter]

Continue doing 4. until your bash exits. I needed 66 attempts for the root directory "/" and command "qqq". With the command "q" it was 51 attempts.
The tested locale is de_DE.UTF-8 for LANG, LC_..., and LANGUAGE on ubuntu,
bash has version 4.3-7ubuntu1.3,
xterm has version 297-1ubuntu1.
Since the behavior is not deterministic on the user input, it looks like a memory corruption issue or a race. Any help?