tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Seán Coffey <sean.cof...@oracle.com>
Subject Re: Crash in java.util.zip.Deflater.deflateBytes
Date Mon, 24 Feb 2014 23:39:48 GMT
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>


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


Mime
View raw message