<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-03 4:23 GMT+02:00 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Jul 02, 2014 at 06:53:09PM -0700, Eliot Miranda wrote:<br>
<div><div class="h5">><br>
> On Wed, Jul 2, 2014 at 5:08 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
><br>
> ><br>
> > On Wed, Jul 02, 2014 at 03:48:03PM -0700, Eliot Miranda wrote:<br>
> > ><br>
> > > On Wed, Jul 2, 2014 at 3:39 PM, Nicolas Cellier <<br>
> > > <a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
> > > ><br>
> > > > Anyway, it happens that I cannot publish because there is a bug in my<br>
> > > > image (mostly an updated trunk image)...<br>
> > > > I'm currently stuck with ZipWriteStream(DeflateStream)>>updateHashAt:<br>
> > > > which tries to write at position 65537 in a buffer of length 65536<br>
> > > > Huh?<br>
> > > ><br>
> > ><br>
> > > Ah, I've seen this recently too! I think it's just a corrupted mcz<br>
> > > package. Delete the package and download a fresh one and you could find<br>
> > > the bug evaporates.<br>
> ><br>
> > I saw it last weekend too. I thought that it was an improbable edge<br>
> > condition,<br>
> > so I did not mention it on squeak-dev until I could explain the bug.<br>
> ><br>
> > It is not a corrupted mcz. In my case, the failure occurred while trying to<br>
> > write a new mcz.<br>
> ><br>
> > We should move this to squeak-dev and figure out what is going on.<br>
> ><br>
><br>
</div></div>> That triggers my memory. I had a method with corrupted source, perhaps<br>
> wide characters. That broke the writer. I fixed it by fixing the method<br>
> source code. Where the corruption came from I can't say.<br>
<br>
I would not be surprised if it is something to do with wide characters. I<br>
vaguely recall that we fixed a similar sounding problem elsewhere in the<br>
system recently. Unfortunately I cannot remember what it was.<br>
<br>
In any case, I am attaching a png of the debug window for the problem as I<br>
encountered it last weekend. This will need to be turned into a repeatable<br>
test case.<br>
<br>
Dave<br>
<br>
<br></blockquote><div>Nope. it was a problem of encoding that I changed in .mcz sometimes ago at least in <a href="http://snapshot.st">snapshot.st</a>.</div><div>Before this change, some buffer started as a ByteString, then become WideString at some point...<br>
Since the bytes of the buffer were picked and copied to another ByteArray with our wonderfull Stream, here is what happened:<br>- that more or less was corresponding to a change of encoding (CP1252 to UTF32 some endianness) in the middle of the file<br>
</div><div>- 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 !<br></div><div>- and only n bytes would have been written instead of n characters !<br>
Gasp, a real mess.<br></div><div>After my changes all is first encoded in UTF8 then compressed.<br><br></div><div>The problem we observe here is completely independent.<br></div><div>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.<br>
I've saved the image with debugger opened for being able to reproduce at will.<br>Unfortunately, my case is several million bytes long (VMMaker), not a joy to debug.<br></div></div><br></div></div>