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
