Thanks for the pointers. I have seen most of the bugs you reference.
I've taken a few of the testcases mentioned also but haven't reproduced
the crash. The crashes I've seen occur in the zlib deflate_slow
function. Ideally the JVM shouldn't crash but given the various factors
at play, it seems like the JNI layer isn't able to handle all scenarios.
JDK 6 is built with zlib 1.1.3 libraries. I'd certainly investigate
further if I had a reproducer.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53725 looks
interesting given that it's fixed in tomcat 7.0.30 and the crashes I've
seen are on tomcat 7.0.29.A. I realise the initial report states an
IOException is seen but wonder if the data could manifest in other ways
so as to cause SEGV for the native deflate calls.
regards,
Sean.
On 19/02/14 17:51, Mark Thomas wrote:
On 19/02/2014 17:03, Seán Coffey wrote:
Hi,
I work in the JDK team and have a few reports of the JVM crashing in
lead on calls from the Apache Coyote stack. A typical trace looks like :
Good to see Oracle taking an interest in this bug.
Is anyone on this list aware of similar issues ?
From memory, there have been a number of reports over several years. A
quick search of the archives found this which looks to be the same issue:
http://tomcat.markmail.org/thread/i5u4sokqczmryzql
This might be related:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55737
There are probably more.
As far as I recall bugs in the FlushableGZIPOutputStream have resulted
in corrupted output rather than a JVM crash:
https://issues.apache.org/bugzilla/show_bug.cgi?id=52121
https://issues.apache.org/bugzilla/show_bug.cgi?id=53725
To re-iterate a point I have made elsewhere on this topic,
FlushableGZIPOutputStream is not doing anything it shouldn't. It isn't
playing games with reflection to access internals. It is a straight
sub-class of GZIPOutputStream and everything it is doing is via the
published API for GZIPOutputStream. There is no way that anything that
that sub-class does should be capable of triggering a JVM crash.
FlushableGZIPOutputStream may have a bug that may be triggering the
crash but the fact that a crash occurs at all is a clear JVM bug.
The above issue was
seen with JDK 6 and Tomcat 7.0.29.A. Was there any instances of multiple
threads accessing the same stream concurrently ?
In all of the instances I have seen there shouldn't have been more than
one thread accessing the stream but it is possible for an application to
retain a reference to a stream which can result in multiple threads
accessing the same stream.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
