[prev in list] [next in list] [prev in thread] [next in thread]
List: pkgsrc-users
Subject: Re: pkgin oddity
From: Patrick Welche <prlw1 () cam ! ac ! uk>
Date: 2013-09-10 15:03:42
Message-ID: 20130910150342.GA1906 () quark
[Download RAW message or body]
On Tue, Sep 10, 2013 at 10:15:21AM +0100, Patrick Welche wrote:
> On Wed, Sep 04, 2013 at 04:18:21PM +0100, Patrick Welche wrote:
> > client# pkgin update
> > pkg_summary.gz 100% 310KB 309.6KB/s 309.6KB/s 00:00
> > pkgin: inflate failed
> >
> > pointing at pkg_summary.gz file created by pkg_comp. Just in case, the same
> > is true with one created with
>
> $ gzip -tv pkg_summary.gz
> pkg_summary.gz: OK
>
> yet -current zlib's inflate() as called by external/decompress fails
> with Z_DATA_ERROR
XXX actually it's Z_BUF_ERROR.
pkgin's external/decompress.c calls inflate() with a "flush parameter"
of Z_FINISH. To quote inflate.c:
the only thing the flush parameter actually does is: when flush
is set to Z_FINISH, inflate() cannot return Z_OK. Instead it
will return Z_BUF_ERROR if it has not reached the end of the
stream.
Tracing pkgin, about to leave inflate.c:1160 inflate() with
(gdb) print *state
$21 = {mode = MATCH, last = 1, wrap = 3, havedict = 0, flags = 2056,
dmax = 32768, check = 3965490129, total = 3152250, head = 0x0, wbits = 15,
wsize = 32768, whave = 32768, write = 0,
window = 0x7f7ff7bb5000 "PENDS=kpathsea>=3.5.7\nCOMMENT=Conditionally include \
text\nSIZE_PKG=5218\nBUILD_DATE=2013-02-25 16:45:07 \
+0000\nCATEGORIES=print\nHOMEPAGE=http://www.tug.org/texlive/\nLICENSE=\nMACHINE_ARCH=x86_64\nOPSYS=Net"..., \
hold = 15, bits = 4, length = 219, offset = 1593, extra = 9, lencode = \
0x7f7ff7bb2550, distcode = 0x7f7ff7bb2e20, lenbits = 9, distbits = 6, ncode = 17, \
nlen = 286, ndist = 30, have = 316, next = 0x7f7ff7bb2fa0, ...
(gdb) print *strm
$22 = {
next_in = 0x7f7ff7bad2b7 \
"\315\n\216p5\r76\320E\f\253\275\025\036S'^\326\023\r\276\306\nAh\252\067\364\201Y\276 \
\027\236MS\221\366l\\\b\237U\030\204\212\250~-\236\330\070\274^y\003i*\026\233\064\312 \
y\326\224x\351Dk\361P/e}\003\251%j\370\301\177\002\005\313Hr1a%\205\034\346bS\220\026\ \
005\363t\340s\023\247\035\066\264\310hr\312\063g\231\337\060m\006V\364\031u\310\376\02 \
6\071\221\347\004r\260\342\376b\021\300wP\362\314p\333\367\321\355,]}\265\335\332\t\27 \
0\237\255\252&R\221W\237\027\375M\021\371\245w\312=\267\315\306\a\275\371L\301$\016\n\346\202\025\271\360*&.\234\204eCa\001\062^Nk"..., \
avail_in = 19618, total_in = 295607, next_out = 0x7f7ff450197a "", avail_out = 0, \
total_out = 3152250, msg = 0x0, state = 0x7f7ff7bb2000, zalloc = 0x7f7ff6a0dfb4 \
<zcalloc>, zfree = 0x7f7ff6a0dfde <zcfree>, opaque = 0x0, data_type = 68,
adler = 3965490129, reserved = 140187732532120}
(gdb) print in
$23 = 295607
(gdb) print out
$24 = 3152250
(gdb) print flush
$25 = 4 == Z_FINISH
(gdb) print ret
$26 = 0 == Z_OK
then ret=Z_BUF_ERROR (-5):
1160: if (((in == 0 && out == 0) || flush == Z_FINISH) && ret == Z_OK)
1161: ret = Z_BUF_ERROR;
so in and out are not zero => haven't reached end of stream?
Cheers,
Patrick
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic