You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Michael Hartle <mh...@hartle-klug.com> on 2001/09/25 15:30:10 UTC
Sun confirmed bug in JPEGEncoder, affecting Batik
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,
Michael Hartle,
Hartle & Klug GbR
Re: Sun confirmed bug in JPEGEncoder, affecting Batik
Posted by Stefano Mazzocchi <st...@apache.org>.
Michael Hartle wrote:
>
> Stefano Mazzocchi wrote:
>
> >Oh, I was myself very puzzled by this one but after applying your patch
> >I can confirm that it works much better (and interesting enough, faster
> >for small images, well, of course, slower for bigger ones)
> >
> Faster for small images ? Interesting.
Or maybe not: this was a perception and I don't have any number to back
this up so it might be a total illusion given by the new sense of
stability :)
> So far, I did not get any
> response from the Batik development list, and there is no update on the
> CVS either; I checked it just a few minutes ago.
It will come, those guys are pretty deep into java and graphics. If they
don't push to fix it, nobody will.
> >Which makes you a perfect candidate for another "real-life howto" of the
> >series that Sergio is going to start this weekend. If you find a few
> >hours and the will to do it, we would all be very grateful. You know,
> >those things are *very* useful when you have to go to your boss and say
> >"let's use this stuff" and they say "Cocoon? how much does it cost?" and
> >you say "it's free and it's very powerful".
> >
> I looking forward to contribute my results in terms of resulting
> documentation, code and test results back to the Cocoon project when
> Cocoon2 has been integrated and is being deployed. I am working as an
> external consultant, though, and have to check some legal aspects, but I
> am quite positive.
Great news. Keep up the great work.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Sun confirmed bug in JPEGEncoder, affecting Batik
Posted by Michael Hartle <mh...@hartle-klug.com>.
Stefano Mazzocchi wrote:
>Oh, I was myself very puzzled by this one but after applying your patch
>I can confirm that it works much better (and interesting enough, faster
>for small images, well, of course, slower for bigger ones)
>
Faster for small images ? Interesting. So far, I did not get any
response from the Batik development list, and there is no update on the
CVS either; I checked it just a few minutes ago.
>Which makes you a perfect candidate for another "real-life howto" of the
>series that Sergio is going to start this weekend. If you find a few
>hours and the will to do it, we would all be very grateful. You know,
>those things are *very* useful when you have to go to your boss and say
>"let's use this stuff" and they say "Cocoon? how much does it cost?" and
>you say "it's free and it's very powerful".
>
I looking forward to contribute my results in terms of resulting
documentation, code and test results back to the Cocoon project when
Cocoon2 has been integrated and is being deployed. I am working as an
external consultant, though, and have to check some legal aspects, but I
am quite positive.
Best regards,
Michael Hartle
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Sun confirmed bug in JPEGEncoder, affecting Batik
Posted by Stefano Mazzocchi <st...@apache.org>.
Michael Hartle wrote:
>
> Stefano Mazzocchi wrote:
>
> >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.
> >
> I was close to sweating blood on this one as at a clients site, the
> system kept on crashing. The whole navigation of this intranet website
> is being autogenerated from a central source when needed, neatly
> following a lengthy design specification, giving this bug every
> opportunity to show up. Since the patch has been applied, this Win2000
> system is close to being rock-stable. Best of all was that I needed to
> submit 3 bug reports to convince Sun that this bug was existant.
Oh, I was myself very puzzled by this one but after applying your patch
I can confirm that it works much better (and interesting enough, faster
for small images, well, of course, slower for bigger ones)
> >Anyway, many thanks for the workaround: I'll apply it to my code, test
> >it heavily and report ASAP.
> >
> You're welcome ;) I am currently connecting Documentum 4i and Cocoon as
> a standard solution for an enterprise-wide deployment, and I am grateful
> for the flexibility and power of Cocoon2.
Which makes you a perfect candidate for another "real-life howto" of the
series that Sergio is going to start this weekend. If you find a few
hours and the will to do it, we would all be very grateful. You know,
those things are *very* useful when you have to go to your boss and say
"let's use this stuff" and they say "Cocoon? how much does it cost?" and
you say "it's free and it's very powerful".
All the usual management crap. Interesting enough, with
sort-of-recession hitting the world, commercial software ramps up
compared to OSS one due to this "lack of security" that everybody seems
to breath in the air. So, having documents that prove with numbers and
commercial test cases (expecially if connected to well-known commercial
products like Documentum) are going to be unbeatable as a way to change
your boss' mind when he wants to go .NET and you picture yourself
submerged with VB.NET books and plagued by MS-certified consultants.
Think about it, people, each one of us might be the very next.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Sun confirmed bug in JPEGEncoder, affecting Batik
Posted by Michael Hartle <mh...@hartle-klug.com>.
Stefano Mazzocchi wrote:
>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.
>
I was close to sweating blood on this one as at a clients site, the
system kept on crashing. The whole navigation of this intranet website
is being autogenerated from a central source when needed, neatly
following a lengthy design specification, giving this bug every
opportunity to show up. Since the patch has been applied, this Win2000
system is close to being rock-stable. Best of all was that I needed to
submit 3 bug reports to convince Sun that this bug was existant.
>Anyway, many thanks for the workaround: I'll apply it to my code, test
>it heavily and report ASAP.
>
You're welcome ;) I am currently connecting Documentum 4i and Cocoon as
a standard solution for an enterprise-wide deployment, and I am grateful
for the flexibility and power of Cocoon2.
Best regards,
Michael Hartle
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Sun confirmed bug in JPEGEncoder, affecting Batik
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Sun confirmed bug in JPEGEncoder, affecting Batik
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org