Ctrl+C kills applications that shouldn't be killed

[genki@…]

When you start a bunch of apps like this: Pulse & Screen &

And then hit Ctrl+C in the terminal the apps will be killed. In BeOS this only works when you start the application without the "&".

After the first (non-built-in) command has been run, Ctrl-C quits the Terminal. E.g. run "ls" in a fresh Terminal, press Ctrl-C, and *plop* the Terminal is gone. Tested in vmware and qemu on Linux. hrev20359

[genki@…]

I reinitialized my partition, installed-haiku and the problem went away.

Something must have been wrong with the system. Sorry about that.

[axeld]

I'd rather reopen this bug. There is definitely something wrong with the scope of the signals sometimes, at least I observed this behaviour as well in the past.

[jackburton]

I found a very simple way to reproduce this:

• Open Terminal.
• Start "top" in the Terminal
• Hit CTRL-C.

Terminal closes as well. Only top should exit, right ?

[axeld]

Actually, those are different bugs. Originally, a control-C killed apps earlier started by the shell. That the Terminal is now closed then (you don't even have to run any app besides the shell in there) is a relatively young problem, probably be caused by the changes I made to the TTY driver.

[johndrinkwater]

Ctrl+C behaviour appears to have been fixed recently in hrev17338; just adding a note.

[korli]

the original problem (Ctrl+C kills backgrounds applications) seems fixed. the top problem described by Stefano remains.

[axeld]

Are you sure about that, J?r?me? I can't reproduce this anymore since the waitpid() fix.

[korli]

Axel, I tested this morning with rev17381 linux image on VPC: When I hit Ctrl+C while top is running, the Terminal is closed. And about the same behavior without Ctrl+C, running "which ps" also closes the Terminal.

[korli]

I deactivated a flag in revision 17431 which would cause bash to use sigsetjmp/ siglongjmp instead of setjmp/longjmp. At least on R5 it fixes the problem I had. I'll test on Haiku later. If the problem is fixed on Haiku as well, it would show a bug in our sigsetjmp/ siglongjmp implementation (see a new test app sigsetjmp_test.c).

[korli]

Ok, I tested on Haiku, and the bug is still here. sigsetjmp_test succeeds on Haiku as well. Moreover I tested with Dano bash binary and it behaves the same as ours. I reverted my change in bash config.h.

[nkoren@…]

I can confirm that this bug still exists, with an added twist -- once the terminal has been killed with a ctrl-C, it can't be reopened. This is happening with rev18509, running under Qemu.

[JamesB192]

A minor twist it seams that if you open a second window ctrl-c will not instantly kill off either terminal window. at least in build 18908.

[axeld]

Since I can only very rarely reproduce this, maybe Jérôme wants to own that bug for a while ;-)

[jackburton]

MiniTerminal is not affected by this problem. This could be an hint that something's wrong within Terminal itself ?

[jackburton]

More testing:

• start terminal
• hit CTRL-C. It doesn't close the terminal (correctly).
• start top with "top -n 1" (so it does one iteration then exits)
• when top quits, hit CTRL-C again. The terminal will now quit.

[axeld]

Still doesn't happen over here :-/

[wkornewald]

I used VMware with hrev19840 (from haikuhost.com). In the Terminal that is automatically opened after boot I typed: ping google.com While the ping ran I pressed CTRL+C. The Terminal got killed, too (and after that I couldn't open the Terminal as described in #627).

[marcusoverhagen]

I can confirm the ping problem as described by wkornewald with vmware and hrev19988 (and a couple of earlier ones), including the inability to open another Terminal from Deskbar after that.

[korli]

Here is a (workaround) fix for the CTRL+C problem:

Index: src/bin/bash/execute_cmd.c =================================================================== --- src/bin/bash/execute_cmd.c (révision 20011) +++ src/bin/bash/execute_cmd.c (copie de travail) @@ -221,7 +221,7 @@

/* Non-zero if we have just forked and are currently running in a subshell

environment. */

-int subshell_environment; +int subshell_environment = 0;

/* Currently-executing shell function. */ SHELL_VAR *this_shell_function;

Thoughts ?

[axeld]

Replying to korli:

-int subshell_environment; +int subshell_environment = 0; Thoughts ?

Well, since global variables are always initialized with zeros, this change shouldn't do anything at all. If it doesn't make a difference in the executable, GCC is a little dumb, at least :-) Anyway, maybe this hints to a problem in the loader?

[korli]

Replying to axeld:

Replying to korli:

-int subshell_environment; +int subshell_environment = 0; Thoughts ?

Well, since global variables are always initialized with zeros, this change shouldn't do anything at all. If it doesn't make a difference in the executable, GCC is a little dumb, at least :-) Anyway, maybe this hints to a problem in the loader?

I made a diff with generated objects. The main change is the subshell_environment is added to the BSS section with the patch. At runtime loader level: without the patch, the vm adress of subshell_environment is located in sh_seg2rw (ANON elf flag), an area created with _kern_create_area. With the patch, the vm adress of subshell_environment is located in sh_seg1rw, an area created with sys_vm_map_file. Hope this helps.

[diver]

Here is another example: type alert fortune in terminal and hit return. Tested on linux via vmware with hrev20316.

[jackburton]

That bug seems to be fixed. At least I cant' reproduce it anymore in latest revisions.

[jackburton]

I wonder if it was my latest changes to Terminal... anyway it's gone for real.

[axeld]

If not, we can still reopen it any day :-) As you know, I could almost never reproduce it, maybe now it's your turn to do that :)) Still, it would be nice to know what change did it.

[axeld]

And there we are again. #1091 is a duplicate of this one.

[bonefish]

Added a description of the remaining bug to the comment.

[bonefish]

Probably another symptom of the same bug:

echo $(ls)

The Terminal closes. Not sure whether before or after everything has been printed.

[jackburton]

Replying to bonefish:

Probably another symptom of the same bug:

echo $(ls)

The Terminal closes. Not sure whether before or after everything has been printed.

Isn't this the problem described in bug #928 ?

[bonefish]

Replying to jackburton:

Replying to bonefish:

Probably another symptom of the same bug:

echo $(ls)

The Terminal closes. Not sure whether before or after everything has been printed.

Isn't this the problem described in bug #928 ?

Yep, it might even be related to #627.

[bonefish]

To avoid duplicated effort, I'm currently working on this problem as well as on bugs #627 and #928.

[bonefish]

Fixed in hrev20402.

[korli]

You did it ! My hero :=)

[jackburton]

Oh-ho. Looks like this happens again.

[bonefish]

I analyzed the problem a bit. From the kernel point of view the kernel does everything right. When e.g. "Screen &" is run in the shell the following happens:

• fork_team()
• sigprocmask() for the child with SIG_SETMASK and an empty signal set.
• exec_team()

setpgid() is not invoked for the child. This means, the child is still in the shell's process group and SIGINT is NOT blocked. IOW, on Ctrl-C a SIGINT is delivered to all processes in the the process group -- the shell and Screen -- and Screen, which (unlike the shell) doesn't have a special SIGINT handler, is terminated.

According to the bash man page (under "SIGNALS"): "Non-builtin commands run by bash have signal handlers set to the values inherited by the shell from its parent. When job control is not in effect, asynchronous commands ignore SIGINT and SIGQUIT in addition to these inherited handlers."

Apparently the last part doesn't happen, as the forementioned call to sigprocmask() clears the formerly blocked SIGINT and SIGQUIT. In the bash sources it also looks like this is intended, though I don't see how this would comply with the quotation from the man page and the expected behavior.

Maybe this is a bash bug, which just no one has noticed, since everyone else uses job control. Because in that case setpgid() is invoked for the child (verified with strace under Linux), and the SIGINT won't be delivered to it in the first place.

Any other ideas?

PS: We should implement job control support. It doesn't look overly complicated to do that and it's definitely a nice feature.

[axeld]

Thanks! Since a few revisions, the signal handlers are cleared in exec() - that weren't done before. Quoting the description of sigaction() from the Open Group Base Specifications:

"Once an action is installed for a specific signal, it shall remain installed until another action is explicitly requested (by another call to sigaction()), until the SA_RESETHAND flag causes resetting of the handler, or until one of the exec functions is called."

Since this ticket has been reopened, maybe the reappearance was caused by this change. That would at least justify to open a new ticket, as the original problem was indeed fixed.

PS: feel free to implement job control :-)

[bonefish]

I just tested our bash version under BeOS R5 and things work as expected. So this is apparently not a bash problem. I guess I'll have to do a little more analyzing...

[bonefish]

I believe I fully understand the problem now. Your change (resetting the signal handlers) is indeed the cause. If the OS does not support job control, bash blocks SIGINT/SIGHUP of asynchronous children by installing a SIG_IGN signal handler (via sigaction()). Clearing the signal handlers on exec() undoes that and we run into our bug.

POSIX has been requiring job control for some time now, which is why clearing the signal handlers is required too, but one can't do that without job control support (BeOS doesn't). So for us it's either implementing job control support or reverting your change. I'll have a close look...

[bonefish]

Closing this bug now. The original problem had already been fixed. I've enabled job control in bash in hrev22061, which cures the symptoms. Some kernel support is missing, so the shell will not work smoothly yet. Working on it...

Please don't reopen.