harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Wilson <jessewil...@google.com>
Subject Re: Build failed in Hudson: Harmony-1.5-head-linux-x86_64 #563
Date Mon, 23 Nov 2009 20:19:16 GMT
On Mon, Nov 23, 2009 at 8:40 AM, Jesse Wilson <jessewilson@google.com>wrote:

> Rolled back as r883400. I'll investigate the Pack200 test problems and push
> this back in after code freeze.
>

FYI: The root problem is a bug in our ZIP decoding. It fails to cope with
Z_SYNC_FLUSH blocks and crashes. I've submitted a failing testcase that
demonstrates the problem:
  http://svn.apache.org/viewvc?view=revision&revision=883478
This test case passes on the RI.

There's an unfortunate consequence of adding flush() support to
deflate/zip/gzip; one I probably should have forseen before checkin. When a
Deflater/Zip/GzipOutputStream is wrapped by a FilterOutputStream (such as
BufferedOutputStream), the compressed datastream will be *different* if we
support flush; even if the user doesn't call flush() directly. Here's why...
  BufferedOutputStream.close() always calls this.flush(), which in turn
calls delegate.flush(),
  DeflaterOutputStream.flush() emits a Z_SYNC_FLUSH block if we support
flushing. If we don't support flushing, that block isn't emitted.
As far as I'm concerned, supporting flush is the right thing to do. It's
essential for any kind of compressed interactive network channel, such as
XEP-0138 <http://xmpp.org/extensions/xep-0138.html> for compressed instant
messaging streams.

I'll investigate fixing the Jar bug...

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message