Opened 14 years ago

Closed 12 years ago

#113 closed bug (fixed)

Ctrl+C kills applications that shouldn't be killed

Reported by: genki@… Owned by: bonefish
Priority: critical Milestone: R1
Component: System/Kernel Version:
Keywords: Cc: diver, axeld, marcusoverhagen, bonefish
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description (last modified by bonefish)

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

Change History (47)

comment:1 by genki@…, 14 years ago

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

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

comment:2 by genki@…, 14 years ago

Resolution: invalid

comment:3 by genki@…, 14 years ago

Status: newclosed

comment:4 by axeld, 14 years ago

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.

comment:5 by axeld, 14 years ago

Resolution: invalid

comment:6 by axeld, 14 years ago

Status: closedreopened

comment:7 by diver, 13 years ago

Cc: diver added

comment:8 by jackburton, 13 years ago

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 ?

comment:9 by axeld, 13 years ago

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.

comment:10 by johndrinkwater, 13 years ago

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

comment:11 by korli, 13 years ago

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

comment:12 by axeld, 13 years ago

Cc: korli@… added

comment:13 by axeld, 13 years ago

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

comment:14 by korli, 13 years ago

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.

comment:15 by korli, 13 years ago

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).

comment:16 by korli, 13 years ago

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.

comment:17 by nkoren@…, 13 years ago

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.

comment:18 by JamesB192, 13 years ago

Component: System/KernelApplications
Platform: x86

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.

comment:19 by axeld, 13 years ago

Description: modified (diff)
Owner: changed from axeld to korli
Priority: normalcritical
Status: reopenednew

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

comment:20 by jackburton, 13 years ago

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

comment:21 by jackburton, 13 years ago

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.

comment:22 by axeld, 13 years ago

Still doesn't happen over here :-/

comment:23 by wkornewald, 13 years ago

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).

comment:24 by marcusoverhagen, 13 years ago

Cc: axeld marcusoverhagen added
Component: - ApplicationsSystem/Kernel

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.

comment:25 by korli, 13 years ago

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 ?

in reply to:  25 ; comment:26 by axeld, 13 years ago

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?

in reply to:  26 comment:27 by korli, 13 years ago

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.

comment:28 by diver, 12 years ago

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

comment:29 by jackburton, 12 years ago

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

comment:30 by jackburton, 12 years ago

Resolution: fixed
Status: newclosed

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

comment:31 by axeld, 12 years ago

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.

comment:32 by axeld, 12 years ago

Resolution: fixed
Status: closedreopened

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

comment:33 by bonefish, 12 years ago

Cc: bonefish added

comment:34 by bonefish, 12 years ago

Description: modified (diff)

Added a description of the remaining bug to the comment.

comment:35 by bonefish, 12 years ago

Probably another symptom of the same bug:

echo $(ls)

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

in reply to:  35 ; comment:36 by jackburton, 12 years ago

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 ?

in reply to:  36 comment:37 by bonefish, 12 years ago

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.

comment:38 by bonefish, 12 years ago

Owner: changed from korli to bonefish
Status: reopenednew

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

comment:39 by bonefish, 12 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev20402.

comment:40 by korli, 12 years ago

You did it ! My hero :=)

comment:41 by jackburton, 12 years ago

Resolution: fixed
Status: closedreopened

Oh-ho. Looks like this happens again.

comment:42 by bonefish, 12 years ago

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.

comment:43 by axeld, 12 years ago

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 :-)

comment:44 by bonefish, 12 years ago

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...

comment:45 by bonefish, 12 years ago

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...

comment:46 by bonefish, 12 years ago

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.

comment:47 by bonefish, 12 years ago

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.