tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Tomcat JVM Crash
Date Fri, 03 Oct 2014 19:01:39 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jess,

On 10/3/14 2:46 PM, Jess Holle wrote:
> 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.]

The thread that evidently crashed the JVM was a NIO thread, but it's a
good catch that there were APR threads running as well.

Chad, can you disable the APR connector and still reproduce the
problem? Can you create a set of step-by-step instructions for
reproducing this problem so someone outside of your environment can
make it happen?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJULvKSAAoJEBzwKT+lPKRYx6YP/RGiKXeJmLwU9R+jdYP8OSFv
P5xYbMNsNQlGy9rHt9jSH1YH4fOGZRTGByoeLR9gno+9R3sFr5ABg8qXoQD/tqTS
RN9AYHgTjSrraNEG3/LOvHT7KlD+EpINo5iTHHWxFsyltra4k16VgdNX9ueVkAQM
ezE1HWorl6yMPFND/itgftqtQiik0ZPLu0UYGuAA0vbmdJgzYj1xFquP/4xy/0qD
T8WvHjWcWYUHouE3MJ3EGhh+kO1XdCRgLH8TvV2OQDvjPCo2pawpC2s816KEf7XM
xU/AbIDOxE9oM5ccJABEQywHMeC9n2FYwduFe0Ar42qsLIbaqRpUIF7yDRAjokW9
o092uzr626k+l4VlJdTWDH1I0h5DBa3kCkWehBbIAneGbo2arDbhNmtoBMwQCCBo
TKdRUSeeg7CbjpL2DavPLMZFeSSnp7wYnVMyIg9hRHj2X9gOSo/FjxzCfd7cBW+s
QkoSVR8Wc5mMylt4XED4BpzwxQb1HX2efSJkGC5Rqn4HXjekG7itbFrPveQ5n0ff
/D//Pb3OhxoD0E1Eh1ubb8QHi12LoJPFDIDQl4jQ0L2iaEvFQZOYdmyeOJwRQlvA
biXbUinIZPsYWH25QzzVOFsXhD2Oycjp9+XAjFJsuKn+hGpgViqYAEXq1xrU8KFh
jqhYIaRMyXVH3P//Xffo
=Rsxn
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message