Hallo Jonathan,
* Jonathan Nieder [Mon, Dec 09 2013, 02:37:05PM]:
> clone 729941 -1
> reassign -1 apt-cacher-ng 0.7.19-1
> retitle 729941 liblzma5: returns LZMA_OK with avail_in == 0 before done
> found 729941 xz-utils/5.1.1alpha+20120614-2
> tags 729941 + moreinfo
> quit
Ok, fair enough... there is still a bug.
> Eduard Bloch wrote:
>
> > Apparently, on the last cycle of lzma_code(&strm, LZMA_RUN) it does not
> > return LZMA_STREAM_END but LZMA_OK although the strm.avail_in value
> > is zero which means that there is no more data to be expected.
>
> I'm puzzled: where in the documentation does it say that when
> strm.avail_in is zero, that means there is no more output to be
> expected?
It doesn't but my code assumed that if avail_in is zero and the last
output buffer was not completely consumed then we are done and stopped
looping but a "sanity check" somewhere else kicked in and and reported
an error when the stream decoder work was not finished (which means:
LZMA_STREAM_END was not returned).
> Just like zlib, if lzma_code() returns LZMA_OK and strm.avail_in is 0,
> decompression is not necessarily finished yet. liblzma has internal
> buffers, so output is potentially incomplete unless you keep running
> lzma_code() until it returns LZMA_STREAM_END or LZMA_BUF_ERROR.
Maybe really like zlib, maybe not. As far as I remember, zlib always
returned ..._END when the result stream was completely written into the
output buffer. And I have seen liblzma behaving the same way but it's
not the case for the mentioned file(s) according to gdb. Here, the
returned data (n time return buffer size plus one incomplete buffer)
summs up to the total size of the stream but in the last cycle lzma_code
returns LZMA_OK and not LZMA_STREAM_END. Maybe it will become
LZMA_STREAM_END the next time when lzma_code is called but why should we
do the extra round?
> [...]
> > The problematic file is also attached. I will a workaround for now to
> > apt-cacher-ng.
>
> Is the workaround as described above? That's the intended API, so I
> don't consider it a workaround.
Well, no, the thing was/is buggy and the workaround is incorrect, I have
actually realized that myself after double-reading the code. This needs
a fix RSN.
> Any idea how this could be documented better to help people running
> into this in the future?
Maybe it should state that one has to wait for LZMA_STREAM_END to be
returned (or any !=LZMA_OK for errors) and not to add other funny
checks for input/output buffer state.
Regards,
Eduard.
--
<Joey> Ich sagte ja auch, rechte Taste auf dem Panel
<Joey> Ok, sagte ich nicht, dachte ich aber...
-- #Debian.DE
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
