Hi, I think there's a bug in the Compression-ZLib
package in this method: OS.ZLib.GZipReadStream>>checkCrcAndLength "This
class futzing is insanity; see AR46615" |
fileCrcAndLength endOfCompressedInput | fileCrcAndLength := UninterpretedBytes new: 8. endOfCompressedInput
:= interface next_in datum - inputBuffer fixedHeapAddress. inputLimit
- endOfCompressedInput >= 8 ifTrue:
[ fileCrcAndLength replaceBytesFrom: 1 to: 8 with: inputBuffer startingAt:
endOfCompressedInput + 1 ] ifFalse:
[ | footerSplit | "This
means that some (possibly none) of the footer (crcAndLength) is already in the
input buffer and some is still sitting in the sourceStream. We need to figure
out what is the split and put the two pieces together. It's also possible to
just skip back in the sourceStream based on the split value, but I don't think
that imposing positionability on the sourceStream just to make this one bit a
little easier is worth it." footerSplit
:= inputLimit - endOfCompressedInput. "how much of the footer is already
in the inputBuffer" fileCrcAndLength
replaceBytesFrom: 1 to: footerSplit with: inputBuffer startingAt:
endOfCompressedInput + 1. sourceStream next: 8 - footerSplit into: fileCrcAndLength
startingAt: footerSplit + 1]. crc
~= (fileCrcAndLength unsignedLongAt: 1 bigEndian: false) ifTrue: [self
error: 'file crc error']. interface
total_out ~= (fileCrcAndLength unsignedLongAt: 5 bigEndian: false) ifTrue: [self
error: 'file length error'] The parts in red indicate the problem. It
creates an UninterpretedBytes and later on /sometimes/ tries to copy contents
from the sourceStream into it. However, this 2nd method uses at:put:
to write bytes into the UninterpretedBytes and this is not implemented on that
class, resulting in this crash: [1] UninterpretedBytes(Object)>>error: [2] UninterpretedBytes(Object)>>shouldNotImplement [3] UninterpretedBytes>>at:put: [4] ReadStream(PositionableStream)>>next:into:startingAt: [5] OS.ZLib.GZipReadStream>>checkCrcAndLength [6] OS.ZLib.GZipReadStream>>nextBuffer [7] OS.ZLib.GZipReadStream(OS.ZLib.InflateStream)>>endTest [8] OS.ZLib.GZipReadStream(OS.ZLib.InflateStream)>>atEnd [9] OS.ZLib.GZipReadStream(Stream)>>upToEnd One of our customers has had the problem
but I cannot reproduce it. Is there a fix for it? (This is in VW7.7). Thanks, Mark _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
This is AR 61468.
On 10/18/2010 2:08 AM, Mark Plas wrote: > Hi, > > I think there's a bug in the Compression-ZLib package in this method: > > OS.ZLib.GZipReadStream>>checkCrcAndLength > > "This class futzing is insanity; see AR46615" > > | fileCrcAndLength endOfCompressedInput | > > *fileCrcAndLength := UninterpretedBytes new: 8.* > > endOfCompressedInput := interface next_in datum - inputBuffer > fixedHeapAddress. > > inputLimit - endOfCompressedInput >= 8 > > ifTrue: [ fileCrcAndLength replaceBytesFrom: 1 to: 8 with: inputBuffer > startingAt: endOfCompressedInput + 1 ] > > ifFalse: [ | footerSplit | > > "This means that some (possibly none) of the footer (crcAndLength) is > already in the input buffer and some is still sitting in the > sourceStream. We need to figure out what is the split and put the two > pieces together. It's also possible to just skip back in the > sourceStream based on the split value, but I don't think that imposing > positionability on the sourceStream just to make this one bit a little > easier is worth it." > > footerSplit := inputLimit - endOfCompressedInput. "how much of the > footer is already in the inputBuffer" > > fileCrcAndLength replaceBytesFrom: 1 to: footerSplit with: inputBuffer > startingAt: endOfCompressedInput + 1. > > *sourceStream next: 8 - footerSplit into: fileCrcAndLength startingAt: > footerSplit + 1*]. > > crc ~= (fileCrcAndLength unsignedLongAt: 1 bigEndian: false) ifTrue: > > [self error: 'file crc error']. > > interface total_out ~= (fileCrcAndLength unsignedLongAt: 5 bigEndian: > false) ifTrue: > > [self error: 'file length error'] > > The parts in red indicate the problem. It creates an UninterpretedBytes > and later on /sometimes/ tries to copy contents from the sourceStream > into it. However, this 2^nd method uses at:put: to write bytes into the > UninterpretedBytes and this is not implemented on that class, resulting > in this crash: > > [1] UninterpretedBytes(Object)>>error: > > [2] UninterpretedBytes(Object)>>shouldNotImplement > > [3] UninterpretedBytes>>at:put: > > [4] ReadStream(PositionableStream)>>next:into:startingAt: > > [5] OS.ZLib.GZipReadStream>>checkCrcAndLength > > [6] OS.ZLib.GZipReadStream>>nextBuffer > > [7] OS.ZLib.GZipReadStream(OS.ZLib.InflateStream)>>endTest > > [8] OS.ZLib.GZipReadStream(OS.ZLib.InflateStream)>>atEnd > > [9] OS.ZLib.GZipReadStream(Stream)>>upToEnd > > One of our customers has had the problem but I cannot reproduce it. > > Is there a fix for it? (This is in VW7.7). > > Thanks, > > Mark > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |