I believe that the scenario is something like this:

  1. When the cat is interrupted, the trap executes.
  2. Because the command that is interrupted is a loop, the loop_level
     variable is nonzero, and so the wait_for function in jobs.c
     executes ADDINTERRUPT; which increments interrupt_state to nonozero.
  2. The trap logic then wants to executes the interrupt trap command
     "show_error" using parse_and_execute function in builtins/evalstring.c
     which takes that command as a plain string argument.
  3. Because the interrupt_state variable is set, parse_and_execute
     refuses to run the command. Moreover, instead of returning normally,
     it executes a throw_to_top_level.
  4. When the top level receives control, running_trap variable is still
     nonzero, and so when the next command is executed, it neglects
     to set up its name in the appropriate global variable. That
     global variable still contains the command name "cat".


I'm able to address the problem in 4 (incorrect command name) with this simple band-aid patch:

diff --git a/sig.c b/sig.c
index 3b62ea5..61dc9b0 100644
--- a/sig.c
+++ b/sig.c
@@ -59,6 +59,7 @@ extern int last_command_exit_signal;
 extern int return_catch_flag;
 extern int loop_level, continuing, breaking, funcnest;
 extern int executing_list;
+extern int running_trap;
 extern int comsub_ignore_return;
 extern int parse_and_execute_level, shell_initialized;
 #if defined (HISTORY)
@@ -443,6 +444,7 @@ throw_to_top_level ()
   run_unwind_protects ();
   loop_level = continuing = breaking = funcnest = 0;
   executing_list = comsub_ignore_return = return_catch_flag = 0;
+  running_trap = 0;

   if (interactive && print_newline)
     {


However, the real problem is that the ERR trap command is not executing because of the interrupt_state increment.

This will not happen for simple commands, which explains why when we interrupt the plain cat command (not wrapped in a loop), we see the expected error trap behavior.

That's because the wait_for function in jobs.c distinguishes loops/list execution.

This was reported by Keith Thompson in the comp.unix.shell newsgroup, along with repro steps. He also reported to the Bash mailing list:

http://lists.gnu.org/archive/html/bug-bash/2015-01/msg00020.html

I have been investigating this problem, using an expect script to automate the testing,  because it involves manual steps typed into an interactive bash. My repro steps have a slight difference compared to Keith's, which is the result of some discoveries I made.

This is run in the directory where you build bash, so there is a ./bash executable.

When the behavior is incorrect, the last part of the output shows a suspended command called "cat" instead of "sleep".

There is more to the story, however.

#!/usr/bin/expect -f
spawn ./bash --norc
send "echo \$BASH_VERSION\n"
expect "$ "
send "show_error() { echo ERROR; }\n"
expect "$ "
send "trap show_error ERR\n"
expect "$ "
send "cat\n"
sleep 1
send "\003"
expect "ERROR"
expect "$ "
send "sleep 60 &\n"
expect "$ "
send "while true ; do cat ; done\n"
sleep 1
send "\003"
send "\003"
expect "$ "
send "sleep 70 &\n"
expect "$ "
send "jobs\n"
expect "$ "
send "exit\n"