United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4680160 : JVM crash in java.net.ServerSocket.implAccept

Details
Type:
Bug
Submit Date:
2002-05-06
Status:
Closed
Updated Date:
2004-01-28
Project Name:
JDK
Resolved Date:
2002-10-24
Component:
core-libs
OS:
linux_redhat_6.1,linux_redhat_7.2,linux,windows_2000
Sub-Component:
java.net
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.2.1,1.3.1_04,1.3.1_07,1.4.0,1.4.1
Fixed Versions:
1.3.1_10 (10)

Related Reports
Backport:
Backport:
Duplicate:
Duplicate:
Duplicate:
Duplicate:

Sub Tasks

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
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
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



Hardware and Software, Engineered to Work Together