[Pharo-project] A possible bug in GZip streams
Hi, I get a SubscriptOutOfBounds error when I evaluate: | aStream zipStream | aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextStringPut: ''. zipStream nextStringPut: ''. zipStream close. aStream close. aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. zipStream nextString. zipStream nextString. zipStream close. aStream close. The error doesn't happen when I put just one string (instead of two). Do you see something wrong in the code? Should I report a bug? Thanks, MartÃn
I forgot to say that I am working on a recent Pharo 1.3. And it is not only GZipWriteStream but also ZipWriteStream and ZLibWriteStream . MartÃn On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias@gmail.com> wrote:
Hi,
I get a SubscriptOutOfBounds error when I evaluate:
| aStream zipStream |
aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextStringPut: ''. zipStream nextStringPut: ''. zipStream close. aStream close. aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. zipStream nextString. zipStream nextString. zipStream close. aStream close.
The error doesn't happen when I put just one string (instead of two).
Do you see something wrong in the code? Should I report a bug?
Thanks, MartÃn
I forgot to say that I am working on a recent Pharo 1.3. And it is not only GZipWriteStream but also ZipWriteStream and ZLibWriteStream . MartÃn On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias@gmail.com> wrote:
Hi,
I get a SubscriptOutOfBounds error when I evaluate:
| aStream zipStream |
aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextStringPut: ''. zipStream nextStringPut: ''. zipStream close. aStream close. aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. zipStream nextString. zipStream nextString. zipStream close. aStream close.
The error doesn't happen when I put just one string (instead of two).
Do you see something wrong in the code? Should I report a bug?
Thanks, MartÃn
no one? :( On Tue, Dec 6, 2011 at 7:32 AM, Martin Dias <tinchodias@gmail.com> wrote:
I forgot to say that I am working on a recent Pharo 1.3.
And it is not only GZipWriteStream but also ZipWriteStream and ZLibWriteStream .
MartÃn
On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias@gmail.com> wrote:
Hi,
I get a SubscriptOutOfBounds error when I evaluate:
| aStream zipStream |
aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextStringPut: ''. zipStream nextStringPut: ''. zipStream close. aStream close. aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. zipStream nextString. zipStream nextString. zipStream close. aStream close.
The error doesn't happen when I put just one string (instead of two).
Do you see something wrong in the code? Should I report a bug?
Thanks, MartÃn
-- Mariano http://marianopeck.wordpress.com
It is certainly a bug ;-) Strangely, non-empty strings work: | aStream zipStream | aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextStringPut: '123'. zipStream nextStringPut: 'ABC'. zipStream close. aStream close. aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. zipStream nextString. zipStream nextString. zipStream close. aStream close. I guess you could add a guard for the #nextInto: message send in GZipReadStream>>#nextString when the length is 0. But I haven't tried. Sven On 08 Dec 2011, at 16:53, Mariano Martinez Peck wrote:
no one? :(
On Tue, Dec 6, 2011 at 7:32 AM, Martin Dias <tinchodias@gmail.com> wrote: I forgot to say that I am working on a recent Pharo 1.3.
And it is not only GZipWriteStream but also ZipWriteStream and ZLibWriteStream .
MartÃn
On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias@gmail.com> wrote: Hi,
I get a SubscriptOutOfBounds error when I evaluate:
| aStream zipStream |
aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextStringPut: ''. zipStream nextStringPut: ''. zipStream close. aStream close.
aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. zipStream nextString. zipStream nextString. zipStream close. aStream close.
The error doesn't happen when I put just one string (instead of two).
Do you see something wrong in the code? Should I report a bug?
Thanks, MartÃn
-- Mariano http://marianopeck.wordpress.com
On Thu, Dec 8, 2011 at 5:09 PM, Sven Van Caekenberghe <sven@beta9.be> wrote:
It is certainly a bug ;-)
Strangely, non-empty strings work:
Yes, in fact, we found that gzip was not working in some "random" cases and Martin could come to the gulty!
| aStream zipStream |
aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextStringPut: '123'. zipStream nextStringPut: 'ABC'. zipStream close. aStream close.
aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. zipStream nextString. zipStream nextString. zipStream close. aStream close.
I guess you could add a guard for the #nextInto: message send in GZipReadStream>>#nextString when the length is 0. But I haven't tried.
Ok, we will try. Thanks, we wanted to know whether we were doing something wrong or not. Don't you use this stream for Zinc as well ?
Sven
On 08 Dec 2011, at 16:53, Mariano Martinez Peck wrote:
no one? :(
On Tue, Dec 6, 2011 at 7:32 AM, Martin Dias <tinchodias@gmail.com> wrote: I forgot to say that I am working on a recent Pharo 1.3.
And it is not only GZipWriteStream but also ZipWriteStream and ZLibWriteStream .
MartÃn
On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias@gmail.com> wrote: Hi,
I get a SubscriptOutOfBounds error when I evaluate:
| aStream zipStream |
aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextStringPut: ''. zipStream nextStringPut: ''. zipStream close. aStream close.
aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. zipStream nextString. zipStream nextString. zipStream close. aStream close.
The error doesn't happen when I put just one string (instead of two).
Do you see something wrong in the code? Should I report a bug?
Thanks, MartÃn
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
Hi!
I guess you could add a guard for the #nextInto: message send in GZipReadStream>>#nextString when the length is 0. But I haven't tried.
Sven
I think the problem is that this method supposes n >= 1: InflateStream>> next: n into: buffer startingAt: startIndex "Read n objects into the given collection. Return aCollection or a partial copy if less than n elements have been read." | c numRead count | numRead := 0. ["Force decompression if necessary" (c := self next) == nil ifTrue:[^buffer copyFrom: 1 to: startIndex+numRead-1]. "Store the first value which provoked decompression" buffer at: startIndex + numRead put: c. numRead := numRead + 1. "After collection has been filled copy as many objects as possible" count := (readLimit - position) min: (n - numRead). buffer replaceFrom: startIndex + numRead to: startIndex + numRead + count - 1 with: collection startingAt: position+1. position := position + count. numRead := numRead + count. numRead = n] whileFalse. ^buffer Martin
On Thu, Dec 8, 2011 at 2:50 PM, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 08 Dec 2011, at 18:43, Martin Dias wrote:
I think the problem is that this method supposes n >= 1:
Yeah, that is why I propose a guard, maybe in this method
n = 0 ifTrue: [ ^ buffer]
thanks, it fixes the issue (inserted at the beginning of InflateStream>> next:into:startingAt:). The same issue should happen sending InflateStream>>readInto:startingAt:count: I guess we should add some tests in CompressionTests package. I can do it on a couple of days.
but I have no time to analyze the consequences/implications.
Sven
On 08 Dec 2011, at 20:38, Martin Dias wrote:
thanks, it fixes the issue (inserted at the beginning of InflateStream>>next:into:startingAt:).
Great!
The same issue should happen sending InflateStream>>readInto:startingAt:count:
Yes, most probably.
I guess we should add some tests in CompressionTests package. I can do it on a couple of days.
Yes, that would be super. Thanks, Martin. Sven
On Thu, 8 Dec 2011, Martin Dias wrote:
On Thu, Dec 8, 2011 at 2:50 PM, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 08 Dec 2011, at 18:43, Martin Dias wrote:
I think the problem is that this method supposes n >= 1:
Yeah, that is why I propose a guard, maybe in this method
n = 0 ifTrue: [ ^ buffer]
thanks, it fixes the issue (inserted at the beginning of InflateStream>> next:into:startingAt:).
The same issue should happen sending InflateStream>>readInto:startingAt:count:
I guess we should add some tests in CompressionTests package. I can do it on a couple of days.
Yeah, that "fixes" the issue, but why didn't it fail before the "fix", when there was only one string written and read? ;) Levente
but I have no time to analyze the consequences/implications.
Sven
Hi Levente, On Thu, Dec 8, 2011 at 5:44 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Thu, 8 Dec 2011, Martin Dias wrote:
On Thu, Dec 8, 2011 at 2:50 PM, Sven Van Caekenberghe <sven@beta9.be>
wrote:
On 08 Dec 2011, at 18:43, Martin Dias wrote:
I think the problem is that this method supposes n >= 1:
Yeah, that is why I propose a guard, maybe in this method
n = 0 ifTrue: [ ^ buffer]
thanks, it fixes the issue (inserted at the beginning of InflateStream>> next:into:startingAt:).
The same issue should happen sending InflateStream>>readInto:**startingAt:count:
I guess we should add some tests in CompressionTests package. I can do it on a couple of days.
Yeah, that "fixes" the issue, but why didn't it fail before the "fix", when there was only one string written and read? ;)
I don't understand what you mean. But I found something strange when debugging, maybe it's the heisenbug you mentioned before: | aStream zipStream | aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextPut: 5. zipStream close. aStream close. aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. self halt. zipStream next inspect. zipStream close. aStream close. When the #halt happens, I just press "Proceed". One hopes that #next answers 5 but not nil as it actually answers. Do you have a link to the mentioned heisenbug description? MartÃn
Levente
but I have no time to analyze the consequences/implications.
Sven
Tx! On Dec 8, 2011, at 8:38 PM, Martin Dias wrote:
On Thu, Dec 8, 2011 at 2:50 PM, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 08 Dec 2011, at 18:43, Martin Dias wrote:
I think the problem is that this method supposes n >= 1:
Yeah, that is why I propose a guard, maybe in this method
n = 0 ifTrue: [ ^ buffer]
thanks, it fixes the issue (inserted at the beginning of InflateStream>>next:into:startingAt:).
The same issue should happen sending InflateStream>>readInto:startingAt:count:
I guess we should add some tests in CompressionTests package. I can do it on a couple of days.
but I have no time to analyze the consequences/implications.
Sven
On Thu, 8 Dec 2011, Mariano Martinez Peck wrote:
no one? :(
This case has at least 3 different bugs (in Squeak). One of them is a heisenbug. :) Levente
On Tue, Dec 6, 2011 at 7:32 AM, Martin Dias <tinchodias@gmail.com> wrote:
I forgot to say that I am working on a recent Pharo 1.3.
And it is not only GZipWriteStream but also ZipWriteStream and ZLibWriteStream .
MartÃn
On Mon, Dec 5, 2011 at 10:47 AM, Martin Dias <tinchodias@gmail.com> wrote:
Hi,
I get a SubscriptOutOfBounds error when I evaluate:
| aStream zipStream |
aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextStringPut: ''. zipStream nextStringPut: ''. zipStream close. aStream close. aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. zipStream nextString. zipStream nextString. zipStream close. aStream close.
The error doesn't happen when I put just one string (instead of two).
Do you see something wrong in the code? Should I report a bug?
Thanks, MartÃn
-- Mariano http://marianopeck.wordpress.com
participants (5)
-
Levente Uzonyi -
Mariano Martinez Peck -
Martin Dias -
Stéphane Ducasse -
Sven Van Caekenberghe