On 17 Feb 2000, Niels Möller wrote:
> Changing the estimate logic to include an extra byte doesn't really
> fix the bug; it shouldn't matter (except for efficiency) if the extra
> byte is allocated at the start or later. Please try the (untested)
> patch below.
Only adding one to self->max in estimate only retarded the problem. 700KB
came through well, but 17MB died with the same error near to the end...

> > P.s.: BTW why doesn't the protocol itself transfers the original size of
> > the compressed data? Then we souldn't do guesses about how big the data
> > will grow...
> I've been thinking about that as well. We could create a new
> "zlib-lsh" compression method to do something like that. Perhaps the
> length field should compressed too? However, this will only help
> inflating; when deflating we still have to guess and adapt to whatever
> the compression ratio turns out to be.
That's true... Indeed, I thought about 2 additional bytes outside the
payload, but it would touch the secsh-draft deeply...

The patch seems to solve this problem. 17MB comes through well.

Greets,
Keresztg

P.s.: In do_free_zstream is this really good to do?:
  int (*free)(z_stream *z) = z->opaque;
  int res = free(z);
As free() already exists. Probably it's harmless, but it's hurting my
eyes. ;)
P.ss.: Ending a deflating (and not inflating!) zlib_instance in the
server causes to return -3 (Z_DATA_ERROR) by deflateEnd.
According to zlib.h:
     deflateEnd returns Z_OK if success, Z_STREAM_ERROR if the
   stream state was inconsistent, Z_DATA_ERROR if the stream was freed  
   prematurely (some input or output was discarded). In the error case,
   msg may be set but then points to a static string (which must not be
   deallocated).
Any ideas? It seems harmless, but who knows...
(BTW it's saying only "In the error case, msg _may_ be set"!)
P.sss.: What about (verbose) writing some stats in do_free_zstream?
Eg. total_in, total_out and whether it was deflating or inflating?

+ Keresztfalvi Gabor
+ Student of the Budapest University of Technology and Economics 
+ mailto: [EMAIL PROTECTED]  [EMAIL PROTECTED]
+ http://www.sch.bme.hu/~keresztg/




Reply via email to