I guess I should have been more specific about why I think this is the correct resolution:
DataOutputStream.close()<http://java.sun.com/j2se/1.4.2/docs/api/java/util/zip/DeflaterOutputStream.html#close%28%29>claims to close the underlying stream (ios). Ios is then flush()'ed and close()'ed, after it has already been closed. I think the real issue is the addition of the deflateroutputstream close to fix the sun finalizer problem with native zlib (bug 46863<http://old.nabble.com/DO-NOT-REPLY--Bug-46863--New%3A-DeflaterOutputStream-not-closed,-causes-OutOfMemoryError-td22545206.html> ) On Thu, May 20, 2010 at 8:04 AM, <thomas.dewe...@kodak.com> wrote: > Hi Johnathan,. > > jonathan wood <jonathanshaww...@gmail.com> wrote on 05/18/2010 08:29:49 > PM: > > > > Looks like a double close on an output stream... > > IMHO that shouldn't be a problem... > > > I believe the solution is to apply the following to org/apache/ > > batik/ext/awt/image/codec/png/PNGImageEncoder.java, although I'd > > rely on Thomas DeWeese or other committer to verify. > > It seems to me the simplest (and potentially the safest) > would be to modify the IDATOutputStream so that flush does nothing > if no bytes have been written: > > Index: > sources/org/apache/batik/ext/awt/image/codec/png/PNGImageEncoder.java > =================================================================== > --- sources/org/apache/batik/ext/awt/image/codec/png/PNGImageEncoder.java > (revision 897441) > +++ sources/org/apache/batik/ext/awt/image/codec/png/PNGImageEncoder.java > (working copy) > @@ -211,6 +211,8 @@ > } > > public void flush() throws IOException { > + if (bytesWritten == 0) return; > + > // Length > writeInt(bytesWritten); > // 'IDAT' signature > > > - removed ios.flush() and ios.close() since DeflaterOutputStream > > claims to complete the stream write and close the close the underlying > stream > > It seems to me we have gotten in trouble before when we didn't > close > streams. It's possible that doesn't apply here but still I'd feel better > leaving the close calls. I don't feel quite a strongly about the flush > as it is clear buffered data should be flushed before closing. > > Really in my mind the main issue is that you should be able to call > flush whenever you want and not cause real havok which isn't the case > without the proposed patch. > >
