[squeak-dev] Re: [Vm-dev] Bug in writing compressed stream when
saving an mcz (was: New Cog VMs available...)
bert at freudenbergs.de
Mon Jul 21 09:28:39 UTC 2014
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>
>>>>> 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.
> Yes, that is exactly what happened.
>> 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.
> 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
- Bert -
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140721/aeb98573/smime.bin
More information about the Vm-dev