Date: Mon, 18 Mar 2002 15:58:38 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Eugene Grosbein <eugen@grosbein.pp.ru> Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/35969: kernel option PPP_DEFLATE often procudes kernel panics; PPP_BSDCOMP sometimes procudes stalled connections Message-ID: <200203182358.g2INwch65873@apollo.backplane.com> References: <200203160808.g2G880k17109@D00015.dialonly.kemerovo.su> <200203160820.g2G8K1s38158@freefall.freebsd.org> <20020317125834.A419@grosbein.pp.ru> <200203170647.g2H6lQ621576@apollo.backplane.com> <20020318221754.A428@grosbein.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
:I was wrong, your commit wasn't the cause of the panics.
:Now I believe I've isolated the moment of breakage.
:The system updated (or downgraded) to tag=RELENG_4 date=2002.02.22.00.00.00
:does not panic using PPP_DEFLATE but suffers from stalled connections.
:One have to send USR2 to pppd to revive PPP link.
:man pppd says:
:
:SIGUSR2
:...
: tion.)
:
:The system updated to tag=RELENG_4 date=2002.02.22.03.00.00
:quickly panics if PPP_DEFLATE is used. It seems it panics due to
:corrupted kernel area.
:
:There was the only commit to RELENG_4 during this period,
:it patched src/lib/libz/infblock.c and src/sys/net/zlib.c
:The latter file is used by kernel ppp driver.
:
:I'd like to investigate this further but I'm definitly not a kernel hacker.
:The only workaround I've found is using 'nodeflate' option of pppd.
:This effectivly disables usage of deflate compression and eliminates panics
:even for kernel built from sources after 2002.02.22.03.00.00
:
:Eugene Grosbein
Excellent work Eugene!
cvs diff -j "RELENG_4:2002/02/22 00:00:00 GMT" -j "RELENG_4:2002/02/22 03:00:00 GMT"
Indeed the only change is to the zlib code.
Ok, I've spent a little while understanding the code. I believe
I found the bug!
If you look at around line 3954 you will see this:
s->sub.decode.codes = c;
s->sub.decode.tl = tl;
s->sub.decode.td = td;
}
ZFREE(z, s->sub.trees.blens);
s->mode = CODES;
sub.trees is a union with sub.decode, so when s->sub.decode = ...
is done, it tromps all over the s->sub.trees elements. Thus
this ZFREE is in the wrong place.
Plese bring your tree back to the latest -stable and apply the
patch I include below, then tell me if it fixes your crashes.
-Matt
Matthew Dillon
<dillon@backplane.com>
Index: zlib.c
===================================================================
RCS file: /home/ncvs/src/sys/net/zlib.c,v
retrieving revision 1.10.2.1
diff -u -r1.10.2.1 zlib.c
--- zlib.c 22 Feb 2002 02:49:31 -0000 1.10.2.1
+++ zlib.c 18 Mar 2002 23:57:59 -0000
@@ -3951,11 +3951,15 @@
r = Z_MEM_ERROR;
LEAVE
}
+ /*
+ * this ZFREE must occur *BEFORE* we mess with sub.decode, because
+ * sub.trees is union'd with sub.decode.
+ */
+ ZFREE(z, s->sub.trees.blens);
s->sub.decode.codes = c;
s->sub.decode.tl = tl;
s->sub.decode.td = td;
}
- ZFREE(z, s->sub.trees.blens);
s->mode = CODES;
case CODES:
UPDATE
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203182358.g2INwch65873>