On 10/3/2014 1:11 PM, Mark Thomas wrote:
On 03/10/2014 17:07, Chad Maniccia wrote:
Hi,

I have discovered the source of the JVM crashes. I figured it best to share 
with the group because it is quite odd. I have tested this and confirmed with a 
colleague so as odd as it sounds it is reproducible.

  The crash is caused by a combination of Chrome web browser, HTTPS, and posting a form 
with an exact amount of data. If you use HTTP to submit the form=no crash, If you use IE 
and HTTPS=no crash. If you add/remove a single character to the form=no crash. I have 
attached the latest crash log. Please note that Tomcat crashes before it logs the request 
to "localhost_access_log" and before it passes the request to the servlet. This 
problem is present between multiple versions of Java and Tomcat.

Here is another user reporting a similar issue.

https://bugs.openjdk.java.net/browse/JDK-8049855

I did like they suggested and added the following line. This doesn't fix the 
problem but it prevents the server from crashing, you get a blank page instead. 
Why is this?

-XX:CompileCommand=exclude,com/sun/crypto/provider/*.*

Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or Oracle?
Oracle.

Regardless of whether the input is valid or not it should not trigger a
JVM crash.

Agreed.

That said, one thing that really bothers me about including /any/ native additional native libraries (ala JNI) in a Java process (but particularly a Java /server/ process) is that when the JVM experiences a native crash you cannot categorically blame the JVM vendor in this case.

If you /don't/ have any additional native code, then you /can /categorically blame the JVM vendor -- clear and simple.

This is one reason of several reasons that for me using APR in Tomcat is a non-starter.

[Yes, you could always reproduce the issue with Java connectors, but that's painful and there are, of course, other reason for avoiding native libraries, e.g. having to build them across the numerous architectures one supports, rather than simple write-once-run-anywhere.]

--
Jess Holle

Reply via email to