Michael Hartle wrote:
>
> Hello,
>
> recently, we found a bug in Suns native
> sun.awt.image.codec.JPEGImageEncoderImpl.writeJPEGStream(), causing the
> VM to crash when streams where images are being encoded to are somehow
> disconnected (e.g., user pressed stop button, connection reset by peer,
> ...) before the encoding has ended. Sun has confirmed this to be a new
> bug under Bug Id 4502892, which can be seen under
> http://developer.java.sun.com/developer/bugParade/bugs/4502892.html (you
> may have to register with Suns Java Developer Connection, but this is
> free). As far as we were able to test it, Suns JDK 1.3.1, JDK 1.4 beta
> and IBMs JDK 1.3.0 are affected under both Windows 2000 and Linux 2.2.
>
> Attached please find the Test.java, allowing you to test whether your
> plattform is affected by this bug, and a slightly modified
> org.apache.batik.transcoder.image.JPEGEncoder.java which works around
> the issue by buffering the encoded image and thereby isolating the
> faulty native method from problematic stream exceptions. To test whether
> your plattform is affected, have a look at Test.java and test your
> plattform with the attached Java class by typing "javac Test.java",
> followed by "java Test". When this application is being run, it silently
> loops printing dots every 500 ms, having one thread encode a JPEG image
> and another one read only some of it and then closing the connection. We
> rarely saw more than 5-6 dots being printed without the VM crashing.
>
> An unpatched Batik running on an affected JVM cannot reliably being used
> in production systems for server-side image generation; we were running
> a Win2K server with Tomcat 4 and Cocoon2 using Batik for dynamic image
> generation, and it took us more than 2 days to isolate this and write
> the workaround. If you are registered with Suns Java Developer
> Connection and have a spare Bug Vote slot, please be so kind to vote for
> this bug.
>
> Best regards,
Know what? I was *just* ready to file a bug report for the exact same
thing since the (yet to be released) cocoon-based image gallery uses
that class pretty heavily and the JVM keeps on crashing.
First I thought of memory issues (since the image gallery can get quite
a huge amount of memory before all the thumbnails are generated and
cached and browsers can request up to 5/6 images concurrently so go
figure...)
While this is unfortunate, I thing it's better this way: a memory leak
would have been much worse. Anyway, the JPEG code was donated (bought?)
from Kodak: does anybody of you from kodak (you know who you are) know
anything about this? or anybody in Sun (again, you know who you are) can
team to fix this?
Is Jimi (JAI?) providing a pure java alternative to that native code
which is (maybe) more stable?
Anyway, many thanks for the workaround: I'll apply it to my code, test
it heavily and report ASAP.
Ciao.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
