JDK-4784574 : background java process dies by CTRL-C on starting shell
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 3.5,1.3.0,1.3.1,1.4.0,1.4.2
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,linux,solaris_7,solaris_8,solaris_9 generic,linux,solaris_7,solaris_8,solaris_9
  • CPU: x86,sparc
  • Submitted: 2002-11-26
  • Updated: 2012-10-08
  • Resolved: 2003-02-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other Other
1.4.0_04 04Fixed 1.4.1_03Fixed 1.4.2Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
If I start a java process in background using bourne shell and hit CTRL-C
on the shell prompt, java process dies.

Here is how to reproduce

-- have a bourne shell by typing /bin/sh
-- do javac a.java 
   a.java is listed below
-- run a by typing java a &

   This will return to shell prompt because process was started in background.
Now, hit CTRL-C, java process will die.

--------------
a.java

public class a {
    public static void main(String[] args) {
        while (true) {
            System.out.println("I am in while loop");
        }
    }
}
---------------------------

Please make a note that it happens only with java 1.4 and bourne shell.

Here is the output of java -version command


java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)




Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.0_04 1.4.1_03 mantis-beta FIXED IN: 1.4.0_04 1.4.1_03 mantis-beta INTEGRATED IN: 1.4.0_04 1.4.1_03 mantis-b19 mantis-beta tiger-b03 VERIFIED IN: mantis-beta
14-06-2004

EVALUATION This is not a mantis bug. Broken in older release. ###@###.### 2002-11-27 From Engineering: It looks to me like a shell problem, probably SIGINT is delivered to the java process when it is printing to the screen and being Ctrl-C'ed. I'm not sure if it's allowed or not for shell to send SIGINT to background process, but VM must exit if it receives SIGINT. Will be closing this bug as will not fix unless an internal escalation is filed to get JPSE team to fix this in older release. ###@###.### 2002-12-13 Works in next release. JDK 1.4.2 Unless escalated this will not be fixed in older release. Still not sure who's bug this is. When a SIGINT is sent to JVM we must exit. Sigint is being sent from the bin/sh. Need to talk with some engineers to look at this one again. To file an escalation you will need to contact JPSE team. ###@###.### 2003-01-08 Please see workaround.... Bug submitter can re-assign as needed. ###@###.### 2003-01-10 ----------------------------------- Works ok in 1.4.2b05, not working in 1.4.2b04. Dropped hotspot library from b05 into b04 and still not working. It seems that some change was made in j2se between b04 and b05 that allowed this to work. ###@###.### 2003-01-13 ----------------------------------- The fix that went into 1.4.2b05 that caused the SIGINT to be ignored by java is 4747357 - Logging should be initialized lazily. It seems that this fix fixed the problem by accident. From bug 4747357, "Making the initialization of this package lazy eliminates its loading by the core libraries for non-GUI applications.." Running a simple GUI program the problem still exists. This is a Mantis bug also. The LogManager adds a shutdown hook which if no hooks already exist eventually calls Terminator.setup which adds the shutdown hooks for HUP INT and TERM on Solaris. It is the INT hook that is causing the problem. It appears that in csh a background process does not receive the SIGINT signal, therefore unmasking it causes no problems. In a bourne shell SIGINT is sent to its child processes and by default the background/child process masks this signal and subsequently ignores it, so unmasking it through the shutdown hooks causes the vm to handle it. Looks like we need to ignore SIGINT when we are running as a background process. Also making logging initialization lazy may cause other problems for bugs such as 4614121, we need to ensure that the shutdown hooks are being added. ###@###.### 2003-01-15 ----------------------------------- From man sh: The INTERRUPT and QUIT signals for an invoked command are ignored if the command is followed by &. ~~~~~~~ Because the shell implements both foreground and background jobs in the same process group, they all receive the same signals, which can lead to unexpected behavior. csh: Background jobs are immune to signals generated from the keyboard, including hangups (HUP). Other signals have the values that the C shell inherited from its environment. ###@###.### 2003-01-15 ----------------------------------- Note this fix (and also the fix for 4755829) has introduced a new problem. With the fix, no shutdown hook will get executed if the application is started as a background job from shell script. Please see 4850355 for details. ###@###.### 2003-04-18
18-04-2003

WORK AROUND run with -Xrs ###@###.### 2003-01-10
10-01-2003