[squeak-dev] Re: [Vm-dev] Bug in writing compressed stream when
saving an mcz (was: New Cog VMs available...)
eliot.miranda at gmail.com
Sun Jul 20 18:18:18 UTC 2014
On Sun, Jul 20, 2014 at 7:30 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> On Fri, Jul 18, 2014 at 02:06:18PM -0700, Eliot Miranda wrote:
> > On Fri, Jul 18, 2014 at 1:51 PM, David T. Lewis <lewis at mail.msen.com>
> > >
> > > Note that the primitive fallback code is probably still broken, but
> > > perhaps that's a separate issue entirely.
> > >
> > I'm not convinced yet. Certainly if the primitives are all removed and
> > image still fails then the fall;back code is broken. But we need to
> > determine that carefully.
> To follow up on this WRT the Smalltalk that runs if the primitive fails or
> the plugin is not present:
> I made a VM with no ZipPlugin, and tested with this. The failure occurs
> as before. So the presence of a working ZipPlugin is masking an issue in
> image. The issue appears if the plugin is absent, and it appears if the
> fails due the the ivar issue that we have been discussing. The problem is
> when a working ZipPlugin is present.
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.
Sorry I still can't offer a test case, other than the "how to make it fail
> previously discussed.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev