JDK-6273094 : api/java_net/DatagramSocket/index.html#Close
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 5.0u4
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2005-05-19
  • Updated: 2014-02-27
  • Resolved: 2005-05-31
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
5.0u4 b05Fixed
Related Reports
Relates :  
Relates :  
Description
FULL PRODUCT VERSION
java version "1.5.0_04-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-ea-b04)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_04-ea-b04, mixed mode)

FULL OS
SUSE LINUX Enterprise Server 9 (x86_64)
VERSION = 9

AND

Red Hat Enterprise Linux AS release 4 (Nahant)

HARDWARE(SLES)
dual AMD opteron 2.2G
4GB Ram 
HARDWARE(RedHat)
Single AMD 64 1.8G
1GB Ram

A DESCRIPTION OF THE PROBLEM:(On SLES)
This failure occurs when executing JCK-runtime-15a (Build10) using the Xcheck:jni flag.
The test only fails about once every four to five runs though this can vary.
The test passes on removal of the Xcheck:jni flag

A DESCRIPTION OF THE PROBLEM:(On RedHat)
This failure occurs when executing JCK-runtime-15a (Build10) using the Xcheck:jni flag.
The test only fails every run.
The test passes on removal of the Xcheck:jni flag

ERROR OUTPUT
FATAL ERROR in native method: JNI call made with exception pending
	at java.net.PlainDatagramSocketImpl.receive0(Native Method)
	- locked <0x0000002b092f31d0> (a java.net.PlainDatagramSocketImpl)
	at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
	- locked <0x0000002b092f31d0> (a java.net.PlainDatagramSocketImpl)
	at java.net.DatagramSocket.receive(DatagramSocket.java:712)
	- locked <0x0000002b0932f770> (a java.net.DatagramPacket)
	- locked <0x0000002b092f3188> (a java.net.DatagramSocket)
	at javasoft.sqe.tests.api.java.net.DatagramSocket.CloseTests$ThreadReceiver.run(CloseTests.java:61)
jni-fail.sh: line 6:  8041 Aborted                 /export/home/JQA/ts150/JCK15a/jdk1.5.0_04/bin/java -d64 -Xcheck:jni -Xfuture -classpath /net/jqa-store/export/home4/JCK-runtime-15a/classes -Djava.security.policy=/net/jqa-store/export/home4/JCK-runtime-15a/lib/jck.policy javasoft.sqe.tests.api.java.net.DatagramSocket.CloseTests -TestCaseID ALL






###@###.### 2005-05-19 15:08:30 GMT
###@###.### 2005-05-20 10:49:28 GMT
###@###.### 2005-05-20 13:37:31 GMT

Comments
EVALUATION Can not reproduce this with a solaris sparc 64-bit build. Will look into linux 64-bit later. ###@###.### 2005-05-25 10:50:06 GMT See the bug in a linux 64-bit build. An intial investigation shows the root of the bug is exactly as gary.collins said in his comment - solaris/native/java/net/PlainDatagramSocketImpl.c installs an exception and then calls SetIntField. It failed the JCK test: n = NET_RecvFrom(fd, fullPacket, packetBufferLen, 0, (struct sockaddr *)&remote_addr, &len); /* truncate the data if the packet's length is too small */ if (n > packetBufferLen) { n = packetBufferLen; } if (n == JVM_IO_ERR) { if (errno == ECONNREFUSED) { JNU_ThrowByName(env, JNU_JAVANETPKG "PortUnreachableException", "ICMP Port Unreachable"); } else { if (errno == EBADF) { JNU_ThrowByName(env, JNU_JAVANETPKG "SocketException", "Socket closed"); } else { NET_ThrowByNameWithLastError(env, JNU_JAVANETPKG "SocketException", "Receive failed"); } } (*env)->SetIntField(env, packet, dp_offsetID, 0); (*env)->SetIntField(env, packet, dp_lengthID, 0); Exchange the order of JNU_ThrowByName and SetIntField will be able to fix this. ###@###.### 2005-05-28 00:03:53 GMT
25-05-2005