2014-07-03 4:23 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:

> On Wed, Jul 02, 2014 at 06:53:09PM -0700, Eliot Miranda wrote:
> >
> > On Wed, Jul 2, 2014 at 5:08 PM, David T. Lewis <lewis at mail.msen.com>
> wrote:
> >
> > >
> > > On Wed, Jul 02, 2014 at 03:48:03PM -0700, Eliot Miranda wrote:
> > > >
> > > > On Wed, Jul 2, 2014 at 3:39 PM, Nicolas Cellier <
> > > > nicolas.cellier.aka.nice at gmail.com> wrote:
> > > > >
> > > > > Anyway, it happens that I cannot publish because there is a bug in
> my
> > > > > image (mostly an updated trunk image)...
> > > > > I'm currently stuck with
> ZipWriteStream(DeflateStream)>>updateHashAt:
> > > > > which tries to write at position 65537 in a buffer of length 65536
> > > > > Huh?
> > > > >
> > > >
> > > > Ah, I've seen this recently too!  I think it's just a corrupted mcz
> > > > package.  Delete the package and download a fresh one and you could
> find
> > > > the bug evaporates.
> > >
> > > I saw it last weekend too. I thought that it was an improbable edge
> > > condition,
> > > so I did not mention it on squeak-dev until I could explain the bug.
> > >
> > > It is not a corrupted mcz. In my case, the failure occurred while
> trying to
> > > write a new mcz.
> > >
> > > We should move this to squeak-dev and figure out what is going on.
> > >
> >
> > That triggers my memory.  I had a method with corrupted source, perhaps
> > wide characters.  That broke the writer.  I fixed it by fixing the method
> > source code.  Where the corruption came from I can't say.
>
> I would not be surprised if it is something to do with wide characters. I
> vaguely recall that we fixed a similar sounding problem elsewhere in the
> system recently. Unfortunately I cannot remember what it was.
>
> In any case, I am attaching a png of the debug window for the problem as I
> encountered it last weekend. This will need to be turned into a repeatable
> test case.
>
> Dave
>
>
> Nope. it was a problem of encoding that I changed in .mcz sometimes ago at
least in snapshot.st.
Before this change, some buffer started as a ByteString, then become
WideString at some point...
Since the bytes of the buffer were picked and copied to another ByteArray
with our wonderfull Stream, here is what happened:
- that more or less was corresponding to a change of encoding (CP1252 to
UTF32 some endianness) in the middle of the file
- but because the leading byte character did inflate (x4), and the offset
of the copy was not updated, the leading bytes were repeated at some point !
- and only n bytes would have been written instead of n characters !
Gasp, a real mess.
After my changes all is first encoded in UTF8 then compressed.

The problem we observe here is completely independent.
We provide a ByteArray to the Deflate layer, and the Deflate layer can't
cope with it... We can reproduce with pure bytes, no encoding in the loop.
I've saved the image with debugger opened for being able to reproduce at
will.
Unfortunately, my case is several million bytes long (VMMaker), not a joy
to debug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140703/95db3535/attachment.htm