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

[Bert Freudenberg]

On 20.07.2014, at 20:42, David T. Lewis <lewis at mail.msen.com> wrote:

> 
> 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
> 

- Bert -



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140721/aeb98573/smime.bin