JDK-4696207 : Ctrl-C in terminal used to start Sanbox Manager causing the GUI to exit
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: unknown
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2002-06-03
  • Updated: 2002-06-13
  • Resolved: 2002-06-13
Related Reports
Relates :  
JDK-4784574 - background java process dies by CTRL-C on starting shell
Description
Sanbox Manager GUI version 1.03.40 running in the background will terminate when you Ctrl-C in the terminal it was started in if you are using bourne shell (SH).

This does not happen using the older SanSurfer GUI (i.e. version 2.08.48e). 
This does not occur if using KSH or CSH, it only happens when using SH.
Comments
EVALUATION ###@###.### 2002-06-05 This behavior is actually dictated by the platform. It's a combination of two things: 1) The Bourne shell (sh) passes interrupts (e.g. Ctrl-C) on to child processes, while the C shell (csh) and Korn shell (ksh) do not. 2) The Java 1.3 VM (which SANsurfer uses) catches and ignores interrupts. The Java 1.4 VM (which SbM uses) does not catch them, but allows the OS to take the default action, which is to kill the Java application. Java does not provide a way for an application to catch interrupts (Ctrl-C) and handle them itself - it needs to rely on the Java VM for this behavior. This is a Java issue, and is re-assigned to Java; I could not find a category/subcategory for JVM 1.4. The previous evaluator is correct; different unix shells differ on how they pass SIGINT (the default action for CTRL-C) to child processes. The obvious workaround is not to launch the application from sh but rather ksh or csh. If this is not feasible, e.g. since the application is started by a startup script, the jvm can be invoked with the -Xrs "reduced signals" flag. On 1.3.1 and 1.4, this options causes a different set of signal handlers to be used and the signal passed on from sh will not cause the Java program to terminate. Additionally, it is feasible to write a shell or C wrapper program to launch the jvm such that the problematic signals are ignored. While the jvm's behavior with respect to signals could be better documented, it is not a bug for the jvm to terminate if it receives SIGINT; closing as not a bug. ###@###.### 2002-06-12
12-06-2002