JDK-4680160 : JVM crash in java.net.ServerSocket.implAccept
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.2.1,1.3.1_04,1.3.1_07,1.4.0,1.4.1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    linux,linux_redhat_6.1,linux_redhat_7.2,windows_2000 linux,linux_redhat_6.1,linux_redhat_7.2,windows_2000
  • CPU: x86
  • Submitted: 2002-05-06
  • Updated: 2004-01-28
  • Resolved: 2002-10-24
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
1.3.1_10 10Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Description
There is a bug reported by NetBeans team 
http://www.netbeans.org/issues/show_bug.cgi?id=21022
Working with RMI crash JVM

It was originally reported against JDK1.4.0 and pointed to bug 4623152 - JVM crash during dynamic class installation that is fixed in JDK1.4.1-b10. Now our testing reveals another problem and with JDK1.4.1-b10. JVM process crashes or falls into some bad state (request for HttpUrlConnection is send but no response is generated). The bug description on NetBeans.org site contains more information how to reproduce it, thread dumps and other details.

When the IDE runs with -Xcheck:jni the following output is generated. Note that there is no native code provided by the IDE.
 
FATAL ERROR in native method: Null object passed to JNI
    at java.net.PlainSocketImpl.socketAccept(Native Method)
    at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:343)
    - locked <0x450b9f70> (a java.net.PlainSocketImpl)
    at java.net.ServerSocket.implAccept(ServerSocket.java:439)
    at java.net.ServerSocket.accept(ServerSocket.java:410)
    at org.apache.tomcat.service.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:286)
    at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:402)
    at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
    at java.lang.Thread.run(Thread.java:536)

The behavoiur is similar with -Xint switch so it should not be problem of compiler. The stacktrace from core dump will be attached.


###@###.### 2002-09-30
JDK 1.4.1-b21
This bug causes NetBeans 3.4 to crash during execution of RMI application.
The RMI executor uses http java.rmi.server.codebase and java.security.policy.
The http server is netbeans internal httpserver (Apache Tomcat) which crashes
the JVM.
This makes the RMI module hard to use, there is a work around but it is quite complicated for the user.

How to reproduce:
1. Install NB 3.4
2. Create RMI Server Application from the Template
3. Execute it using RMI Executor
4. If the IDE does not crash, terminate the application and start it again.

If JVM is run with -Xcheck:jni
the output is:
FATAL ERROR in native method: Null object passed to JNI
at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353)
        - locked <0x45452858> (a java.net.PlainSocketImpl)
        at java.net.ServerSocket.implAccept(ServerSocket.java:439)
        at java.net.ServerSocket.accept(ServerSocket.java:410)
        at org.apache.tomcat.service.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:286)
        at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:402)
        at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
        at java.lang.Thread.run(Thread.java:536)

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.3.1_10 1.4.1_07 mantis FIXED IN: 1.3.1_10 1.4.1_07 mantis INTEGRATED IN: 1.3.1_10 1.4.1_07 mantis mantis-b05 VERIFIED IN: 1.3.1_10 1.4.1_07 mantis-beta
2004-06-14

EVALUATION The "Null object passed to JNI" error stems from a unchecked call to JNI's NewObject. The returned object is provided to a subsequent JNI call without first checking if NewObject failed. Typically NewObject can only fail if we are out of memory, the ctor throws an exception, or we try to create an instance of an interface or abstract class. In the case of a java.net.Inet4Address (which this test is failing on) the class is a concrete class and the no-arg ctor doesn't throw an exception. It is therefore likely that the exception is an OutOfMemoryError. ###@###.### 2002-10-01 The exception has now been tracked now - it's a ThreadDeath caused by NetBeans stopping an entire thread group. For mantis we'll fix this so that all JNI calls are checked. ###@###.### 2002-10-07
2002-10-07