Smalltalk › Squeak › Squeak - Dev

Possible bug in DeflateStream

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Max Leske

Possible bug in DeflateStream

For those of you that haven’t seen the “Metacello load error” conversation between Dale and me, there seems to be a bug in DeflateStream. I’m quoting myself from the other thread:

I've figured it out. Your were right, the newest Cog VM doesnât exhibit the problem. The problem seems to be the method ZipWriteStream>>deflateBlock:chainLength:goodMatch:. The primitive in that method fails in 4.6 only when I open the 4.6 image with the VM packaged with the 4.5 all-in-one app ('Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.331] 4.5â). The fallback method generates an error.
This is reproducible when using the fallback instead of the primitive with the other VM and a 4.5 image too, so there is definitely something wrong with the Zip implementation. Hereâs a snippet for reproducing the problem:

ZipWriteStream removeSelector: #deflateBlock:chainLength:goodMatch:.

(Installer monticello http: 'http://www.squeaksource.com/MetacelloRepository')
package: 'Gofer-Core-lr.115.mcz';
install.

(Smalltalk at: #Gofer) new
url: 'http://seaside.gemstone.com/ss/metacello';
addPackage: 'ConfigurationOfMetacello';
load

Cheers,
Max

David T. Lewis

Re: Possible bug in DeflateStream

On Fri, Mar 20, 2015 at 02:05:02PM +0100, Max Leske wrote:
> For those of you that haven???t seen the ???Metacello load error??? conversation between Dale and me, there seems to be a bug in DeflateStream. I???m quoting myself from the other thread:
>

This sounds familiar, although I don't have a link to the details. IIRC we
changed something in the image that exposed an existing bug in a primitive,
then fixed that bug. So there were be some combinations of image and VM that
would have a problem.

I'm sorry I can't give a better reference right now, but I think it was discussed
on squeak-dev, and the VM fixes may have been added in VMMaker.oscog-eem.826 (Cog)
and VMMaker-dtl.347 (VMM trunk).

Dave

> >
> > I've figured it out. Your were right, the newest Cog VM doesn??????t exhibit the problem. The problem seems to be the method ZipWriteStream>>deflateBlock:chainLength:goodMatch:. The primitive in that method fails in 4.6 only when I open the 4.6 image with the VM packaged with the 4.5 all-in-one app ('Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.331] 4.5??????). The fallback method generates an error.
> > This is reproducible when using the fallback instead of the primitive with the other VM and a 4.5 image too, so there is definitely something wrong with the Zip implementation. Here??????s a snippet for reproducing the problem:
> >
> > ZipWriteStream removeSelector: #deflateBlock:chainLength:goodMatch:.
> >
> > (Installer monticello http: 'http://www.squeaksource.com/MetacelloRepository' <http://www.squeaksource.com/MetacelloRepository'>)
> > package: 'Gofer-Core-lr.115.mcz';
> > install.
> >
> > (Smalltalk at: #Gofer) new
> > url: 'http://seaside.gemstone.com/ss/metacello' <http://seaside.gemstone.com/ss/metacello'>;
> > addPackage: 'ConfigurationOfMetacello';
> > load
>
>
> Cheers,
> Max
>

Nicolas Cellier

Re: Possible bug in DeflateStream

2015-03-20 14:36 GMT+01:00 David T. Lewis <[hidden email]>:

On Fri, Mar 20, 2015 at 02:05:02PM +0100, Max Leske wrote:
> For those of you that haven???t seen the ???Metacello load error??? conversation between Dale and me, there seems to be a bug in DeflateStream. I???m quoting myself from the other thread:
>

This sounds familiar, although I don't have a link to the details. IIRC we
changed something in the image that exposed an existing bug in a primitive,
then fixed that bug. So there were be some combinations of image and VM that
would have a problem.

I'm sorry I can't give a better reference right now, but I think it was discussed
on squeak-dev, and the VM fixes may have been added in VMMaker.oscog-eem.826 (Cog)
and VMMaker-dtl.347 (VMM trunk).

Dave

If I remember, an inst. var. was added by Eliot in Stream hierarchy and that broke the primitives that were using hardcoded inst. var. offsets.

In newer VM, the primitives have been changed to accomodate for relative offset or something like that.

So a recent VM must be used.

We also had a doubt whether the Smalltalk fallback code was consistent with primitives or not, but I can't remember the conclusions...

Nicolas

> >
> > I've figured it out. Your were right, the newest Cog VM doesn??????t exhibit the problem. The problem seems to be the method ZipWriteStream>>deflateBlock:chainLength:goodMatch:. The primitive in that method fails in 4.6 only when I open the 4.6 image with the VM packaged with the 4.5 all-in-one app ('Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.331] 4.5??????). The fallback method generates an error.
> > This is reproducible when using the fallback instead of the primitive with the other VM and a 4.5 image too, so there is definitely something wrong with the Zip implementation. Here??????s a snippet for reproducing the problem:
> >
> > ZipWriteStream removeSelector: #deflateBlock:chainLength:goodMatch:.
> >
> > (Installer monticello http: 'http://www.squeaksource.com/MetacelloRepository' <http://www.squeaksource.com/MetacelloRepository'>)
> > package: 'Gofer-Core-lr.115.mcz';
> > install.
> >
> > (Smalltalk at: #Gofer) new
> > url: 'http://seaside.gemstone.com/ss/metacello' <http://seaside.gemstone.com/ss/metacello'>;

> > addPackage: 'ConfigurationOfMetacello';
> > load
>
>
> Cheers,
> Max
>