Keresztfalvi Gabor <[EMAIL PROTECTED]> writes:
> On 7 Jan 2000, Niels M�ller wrote:
>
> > That sounds serious. How can I reproduce it? Did you compile both
> > the client and the server with zlib support? That's been working for
> > me for a long time. Or did you compile only one of them with zlib? I'd
> > like to know the details.
>
> I simply 'tar xfz lsh-0.2.1.tar.gz', 'cd lsh-0.2.1', './configure',
> 'make', 'cd src', './lshd -p 4711 -v --debug --trace --enable-core' and in
> an other terminal from the _same_ directory (the same build)
> './lsh -z -p 4711 localhost' and I get the segfault in lshd. I tried it
> with a libz compiled from the downloaded zlib-1.1.3 source, but it didn't
> help.
> BUT: The life gets more complex... If I start the server _only_ with
> './lshd -p 4711' and run the client with './lsh -z -p 4711 localhost'
> (same as above) then I get the segfault in the _client_ (but in the same
> place in the do_zlib function).
>
> So what is the difference? I traced it to:
> - if the server was started with the '-v' parameter then the server
> segfaults.
> - if the server was started without the '-v' parameter then the clients
> segfaults.
> Hey! This seems to be an obscure bug. ;) What the hack correlates
> verbosity and segfault in the zlib glue code?
My guees is that the difference is whether or not the server sends the
SSH_MSG_DEBUG message saying "Key exchange successful". This is the
first message sent that uses compression. Running with --debug will
tell you exactly which packets are sent and received.
> So let's run the programs in gdb:
> - if the server is started with '-v': lshd reaches do_zlib first time and
> in zlib.c at line 156 segfaults because self->f is 0. (Oooops.) lsh hasn't
> reached do_zlib yet!
> - if the server is started without '-v': _lsh_ reaches do_zlib first time
> and in zlib.c at line 156 segfaults because self->f is 0. But _lshd_
> hasn't reached do_zlib yet!
> But why does the verbosity affect who wants first (de)compressing? Maybe
> this is a dead end, but interesting... ;)
> So the other way to go is why self->f is 0? In make_zlib_* I can't find
> the assignment. Indeed I can't find it anywhere...
> Looking in zlib.c after the segfaulting line there is:
> if (rc != Z_OK)
> {
> werror("do_zlib: deflate() or inflate() failed: %z\n",
> self->z.msg ? self->z.msg : "No error(?)");
> Hmmm. In the src directory 'grep inflate *' -> nowhere assigned.
> 'grep deflate *' -> nowhere assigned as well... Then how should lsh/lshd
> know what to call in case of (de)compression?
Ooops. Don't understand why this could ever have worked. The pointers
should be set up properly in make_zlib_instance(). Something like this
(untested):
diff -u -a -r1.21 zlib.c
--- zlib.c 1999/11/16 22:13:49 1.21
+++ zlib.c 2000/01/09 13:34:58
@@ -211,11 +211,13 @@
{
case COMPRESS_DEFLATE:
res->z.opaque = deflateEnd;
+ res->f = deflate;
res->super.codec = do_zlib;
deflateInit(&res->z, closure->level);
break;
case COMPRESS_INFLATE:
res->z.opaque = inflateEnd;
+ res->f = inflate;
res->super.codec = do_zlib;
inflateInit(&res->z);
break;
Now I only wonder why my lsh didn't crash... For some reason
compression must have been disabled.
/Niels
