<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 20, 2014 at 7:30 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br>
On Fri, Jul 18, 2014 at 02:06:18PM -0700, Eliot Miranda wrote:<br>
><br>
> On Fri, Jul 18, 2014 at 1:51 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
> ><br>
</div><div class="">> > Note that the primitive fallback code is probably still broken, but<br>
> > perhaps that's a separate issue entirely.<br>
> ><br>
><br>
> I'm not convinced yet. Certainly if the primitives are all removed and the<br>
> image still fails then the fall;back code is broken. But we need to<br>
> determine that carefully.<br>
<br>
</div>To follow up on this WRT the Smalltalk that runs if the primitive fails or if<br>
the plugin is not present:<br>
<br>
I made a VM with no ZipPlugin, and tested with this. The failure occurs exactly<br>
as before. So the presence of a working ZipPlugin is masking an issue in the<br>
image. The issue appears if the plugin is absent, and it appears if the primitive<br>
fails due the the ivar issue that we have been discussing. The problem is hidden<br>
when a working ZipPlugin is present.</blockquote><div><br></div><div> This explains the appearance of the bug in the first place. Adding the inst vars to ReadStream and WriteStream to fix on:from:to: caused the plugin methods to fail, since values fetched from the streams were no longer as expected due to their offsets changing. This caused the back-up code to run.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Sorry I still can't offer a test case, other than the "how to make it fail recipe"<br>
previously discussed.</blockquote><div><br></div><div>I have a suspicion. If the plugin attempts to store a "byte" outside the 0-255 range, the least significant 8 bits get stored. If the image attempts to store a "byte" outside the 0-255 range, the target morphs to a WideString, which will change the offsets of lots of things.</div>
</div>-- <br>best,<div>Eliot</div>
</div></div>