[squeak-dev] Re: [Vm-dev] Bug in writing compressed stream when saving an mcz (was: New Cog VMs available...)

David T. Lewis lewis at mail.msen.com
Sun Jul 20 18:42:48 UTC 2014


On Sun, Jul 20, 2014 at 11:18:18AM -0700, Eliot Miranda wrote:
>  
> 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>
> > wrote:
> > > >
> > > > 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
> > the
> > > 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
> > if
> > the plugin is not present:
> >
> > I made a VM with no ZipPlugin, and tested with this. The failure occurs
> > exactly
> > as before. So the presence of a working ZipPlugin is masking an issue in
> > the
> > image. The issue appears if the plugin is absent, and it appears if the
> > primitive
> > fails due the the ivar issue that we have been discussing. The problem is
> > hidden
> > 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.

Yes, that is exactly what happened.

> 
> Sorry I still can't offer a test case, other than the "how to make it fail
> > recipe"
> > 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.

That may very well be the case! And this would explain why zip stream code
that has lived happily in the image for a long time now seems to have become
buggy.

Dave



More information about the Vm-dev mailing list