Re: pkgin oddity

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

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\312y\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\026\071\221\347\004r\260\342\376b\021\300wP\362\314p\333\367\321\355,]}\265\335\332\t\270\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