United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4927336 (ch) Interrupt-signal handler improperly installed, causing random exits (lnx)
JDK-4927336 : (ch) Interrupt-signal handler improperly installed, causing random exits (lnx)

Details
Type:
Bug
Submit Date:
2003-09-24
Status:
Closed
Updated Date:
2010-02-20
Project Name:
JDK
Resolved Date:
2003-12-19
Component:
core-libs
OS:
linux
Sub-Component:
java.nio
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2,5.0
Fixed Versions:
5.0 (beta)

Related Reports
Backport:
Backport:

Sub Tasks

Description
Name: mmR10223			Date: 09/24/2003


Filed By       : J2SE-SQA [###@###.###
JDK            : JDK1.5.0-b19s 
JCK            : JCK1.5-runtime (b04)
Platform[s]    : Linux
switch/Mode    : default
JCK test owner : http://javaweb.eng/jck/usr/owners.jto
Falling test[s]: 
        api/java_nio/channels/SocketChannel/index.html#Generated 

JCK1.5-runtime api/java_nio/channels/SocketChannel/index.html#Generated test fails with JDK1.5.0-b19s
on Linux platform only. It is not reproducible on Windows and Solaris platforms.

This test passes for some reason with JDK1.5.0-b20, JDK1.5.0-b19, JDK1.4.2-b28 though is thrown exception
"java.nio.channels.NotYetConnectedException"

Test source location:
=====================
/java/re/jck/1.5/promoted/latest/binaries/JCK-runtime-15/tests/api/java_nio/channels/SocketChannel/GeneratedTests.java

jtr file location:
==================
/net/jtgb4u4c.sfbay/export/sail15/results.2/tiger/b19s/jck15/linux/suse8.0_gnome_server_linux-2/workDir/api/java_nio/channels/SocketChannel/index_Generated.jtr

How to reproduce:
=================
Run the following script (you may need to change its variables)
 
--- script start ---
#!/bin/bash

#KOORI_ONESTOP is your path to koori.sfbay/onestop (/net/koori/onestop, /java/re)
KOORI_ONESTOP="/java/re"

#JCK="/net/linux-15/export/home/java/jck1.5/JCK-runtime-15"
JCK="$KOORI_ONESTOP/jck/1.5/promoted/beta/b04/binaries/JCK-runtime-15"
#JDK="/net/linux-15/export/home/java/jdk1.5.0/linux"
JDK="$KOORI_ONESTOP/jdk/1.5.0/promoted/all/b19/binaries/linux-i586"

CLASSPATH="$JCK/classes:$JCK/lib/javatest.jar"
 
$JDK/bin/java -showversion -cp $CLASSPATH javasoft.sqe.tests.api.java.nio.channels.SocketChannel.GeneratedTests -network.tcpPortRange 0


--- script end ---

Test output:
============
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b19)
Java HotSpot(TM) Client VM (build 20030915105831.kbr.share_baseline_testing-fastdebug1-debug, mixed mode)

java.nio.channels.NotYetConnectedException
	at sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:114)
	at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:139)
	at javasoft.sqe.tests.api.java.nio.channels.SocketChannel.GeneratedTests$Receiver.receiveMeth(GeneratedTests.java:484)
	at javasoft.sqe.tests.api.java.nio.channels.SocketChannel.GeneratedTests$Receiver.run(GeneratedTests.java:497)
java.nio.channels.NotYetConnectedException
	at sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:114)
	at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:139)
	at javasoft.sqe.tests.api.java.nio.channels.SocketChannel.GeneratedTests$Receiver.receiveMeth(GeneratedTests.java:484)
	at javasoft.sqe.tests.api.java.nio.channels.SocketChannel.GeneratedTests$Receiver.run(GeneratedTests.java:497)
result: Failed. unexpected exit code: exit code 189

Specific machine info:
======================
Hostname: linux-2
OS: Suse Linux 8.2 (GNOME2)



======================================================================
###@###.### 10/15/04 10:56 GMT

                                    

Comments
EVALUATION

The process is being terminated by signal 61, which is equivalent to the
real-time signal number 28 which is used by NIO for interrupting threads that
are performing operations at the same time another thread is trying to close the
socket (src/solaris/native/java/net/linux_close.c). It seems there may be a
conflict between NIO's usage of this signal and NPTL's usage of it; looking
through the strace output, more than one sigaction call for this signal number
is being made.

The reason this bug is showing up in the sharing workspace is that the failure
occurs with debug or fastdebug builds; a fastdebug build was provided to SQA for
testing. The failure with java_g began occurring in b08. It appears to have been
a change in the libraries, not the VM, that caused the test to begin failing.
The test passes with a debug build of the sharing VM in a b07 JDK.

###@###.### 2003-10-08


This bug has nothing in particular to do with NPTL.  It's consistently
reproducible using java_g on a RH 7.2 system starting with Tiger b08.

The two invocations of sigaction which show up in the strace output are not a
surprise; one is in the java.net code (as mentioned above) and one is in
java.nio (sun/nio/ch/NativeThread).  Only one of these is really needed, but
both are there out of paranoia and having both does no harm.

Note that you'll see slightly different RT signal numbers depending upon which
version of Linux you use.  On RH 7.2 and RH AS 2.1 SIGRTMIN is 32, while on RH
9 it's 34.

I'm stumped as to why this only shows up with debug builds.  The relevant
library code did not change in Tiger b08, so I suspect that a change in HotSpot
must have caused this.  Reassigning to hotspot/runtime_system for further
evaluation.

-- ###@###.### 2003/11/16

--------------------------------------

b08 is the first promotion to use gcc-3.2. Older JDK was built by egcs-2.91.
There is also a gcc-3.2 build of b07 to help diagnose gcc issues.

Yes, with the same b07 source code, this test can pass without problem when
JDK is built by old gcc (/java/re/jdk/1.5/promoted/b07/binaries/linux-i586), 
but it always fails with new gcc (/java/re/jdk/1.5/promoted/b07/binaries/
linux-i586.as21). So it does look like a gcc problem.

A known gcc issue since b08 is 4885046 (dso_handle is shared among dynamic
libraries), I will try that fix and see if it can also solve the problem here.

###@###.### 2003-11-16

--------------------------------------

Actually, the bug is in sun/nio/ch/NativeThread.c, it does not initialize
sa.sa_flags:

    sigset_t ss;
    struct sigaction sa, osa;
    sa.sa_handler = nullHandler;
    sigemptyset(&sa.sa_mask);
    if (sigaction(INTERRUPT_SIGNAL, &sa, &osa) < 0)
        JNU_ThrowIOExceptionWithLastError(env, "sigaction");

The sigaction() call will pick up whatever random value on the stack as
sa_flags. If it happens to have SA_ONESHOT (or SA_RESETHAND) set, the signal
handler will be reset to SIG_DFL when a INTERRUPT_SIGNAL is received. A
second interrupt signal will kill the Java process.

###@###.### 2003-11-17
                                     
2003-11-17
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger-beta

FIXED IN:
tiger-beta

INTEGRATED IN:
tiger-b32
tiger-beta

VERIFIED IN:
tiger-beta


                                     
2004-06-14



Hardware and Software, Engineered to Work Together