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.