Bug 21022

Created attachment 4869 [details]
HotSpot error file

Created attachment 4870 [details]
examples

The crash of JDK 1.4 on Solaris is caused by JDK bug, on JDK 1.3 the
crash does not occure.

Created attachment 4982 [details]
Stacktrace of internal RMI registry waiting on tomcat op

Created attachment 4983 [details]
RMI registry standalone process

The bug can be splitted into two bugs, first is the crash of JVM (see
P. Knakal attachment id= 4869) problematic Thread is tomcat Thread,
but the  crash is SIGSEGV (Segmentation violation), so JDK not
NetBeans bug.
The seccond is the deadlock of IDE, the deadlock is caused by waiting
on  socket while the URLClassLoader performs HTTP GET operation, there
is no answer from tomcat and also the socket is not closed or
shutdowned by tomcat, so the thread is hanged for standard TCP stay
time (if no setsockopt is used 2 hours). This can be seen from
attached thread dumps (4982,4983) one represents Internal RMI registry
(running
inside in IDE) second represents deadlock of extenral rmiregistry
process. Both stack trace are the same.

RMI WORKARROND:
   In RMI executor set rmi.server.codebase to URL of filesystem where
the RMI application is located. e.g file:///home/me/nbdev/sampledir/.
The URL must end with slash. In this case no tomcat is used.

Possible RMI improvements:

    Do not perform ClassElement.forClass in createNode, this operation
does the following code inside the clazz module:
      ((Class) c)).findResource
("/"+((Class)c)).getName().replace('.','/')+".class")
This yields to URLClassLoader to load the resource of class, this
functionality should be done in special RequestProcessor.
Also there is no reason why to read Class and then to read again its
resource, better way is to use dirrectly the resource.

According to my testing the bug can be reproduced only on JDK1.4 on
Solaris operating system.

Reassigned to internal httpserver module. 

We can't fix JVM crashing. It has to be fixed by JDK team.

Regarding the second problem we need to check if it is common that
internal HTTP server hangs during request dispatching earlier than
communication is established. Now it is reported as a platform
dependent problem that is not 100% reproducible.

Lowering priority. Most likely it is a bug in JDK.

Could we try patch attached to bug #19717 that is related to the same
JVM bug?

According to discussion with Tomas Zezula this won't be fixed in the
IDE. The problem will be documented and workaround exists.

I've check it in the dev build 3.4 & JDK1.4.1_b10

This freeze the IDE. That's good that the workaround exist, but RMI
module is unusable.

Created attachment 5571 [details]
The last thread dump.

This bug was related to JVM bug 4623152. This one is still not fixed
and it seems that workarounds in 19717 doesn't help us. Can you try
the -Xnoclassgc switch. 

Tomas: is there any possibility to implement any workaround on RMI
module side? What are the URLs you are trying to load? Maybe that
newly introduced URLMapper class in openAPI can help us here to find
URL that will use file: or jar: protocol for given fileobject.

I don't think this would solve the problem - rmi can be exported on
one machine and the browser may run on another. Using of http protocol
is essential.

Created attachment 5600 [details]
JVM crash report

Reproduced JVM crashes with NB dev build (Apr 30), Linux (redhat 7.1),
jdk1.4.1-b10 and jdk1.4.0-b92.

I created new RMI activatable and unicast servers execute them,
stopped and executed again and JVM always crashed (error file is
attached). So I can't evaluate the freezing behaviour.

Waived for Forte for Java 4.0

Step for reproducing (NB3.4 dev build, Linux RH7.1, JDK 1.4.0-b72 or
JDK1.4.1-b10). 
- start the rmid_wrapper on port 1098 (from bin directory of the IDE
instalation)
- start the IDE
- start local RMI registry (in Explorer window go to Runtime tab and
select Local registry from context menu on RMI registry node
- create RMI classes. Either use attached examples.tar (extract it
into sampledir that is mounted in explorer) or create new Activatable
and Unicast RMI from templates (you need also create some interface
that will be implemented by these objects). Compile them (you may need
to write some implementation of the method specified by RMI interface).
- execute both servers 
- check that RMI registry and RMI activatable browser show the servers.
- stop runing proces(es) in execution window
- restart RMI registry
- execute both servers again

After this IDE crashes in my environment. Another possibility is that
it will be blocked with possible problem in thread:

	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:343)
	- locked <0x4659ce48> (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)

If this doesn't reveal the problem repeated execution of RMI objects
and RMI registry may help.

The waiver was approved.

JDK bug is reported to JDK team, workaround is documented.
http://developer.java.sun.com/developer/bugParade/bugs/4680160.html

Resolved for 3.3.x or earlier, no new info since then -> closing.

Resolved for 3.3.x or earlier, no new info since then -> closing.