Date: Mon, 21 Feb 2000 21:26:56 +0900 From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp> To: asmodai@bart.nl Cc: sameh@fr.clara.net, freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Panic (TCP) Message-ID: <20000221212656L.shin@nd.net.fujitsu.co.jp> In-Reply-To: <20000221125010.H84100@lucifer.bart.nl> References: <20000221121246.F18727@noc.fr.clara.net> <20000221204008M.shin@nd.net.fujitsu.co.jp> <20000221125010.H84100@lucifer.bart.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
> >Might there be incorrect memory over writing? > > How you mean? I think one possibility of the problem is that some code is incorrectly overwriting some part of the memory, and a tcpcb's tt_persist->c_flags is happen to overwritten. Now I am very much interested in the value of tp->tt_persist->c_flags at panic, if CALLOUT_PENDING and possibly other flags are just set, or completely broken data is written on it. And if later, I am also interested in other values around tp->tt_persist->c_flags, to check what kind of value is written around there. > Debugging tips are welcome, since I am not the biggest bulb wrt > debugging. I am not also, and you might have already known these things, but in case they are useful, -If DDB is specified in kernel config file, and all src/sys tree including sys/compile dir is saved onto another machine, it will be very useful at next panic, because remote GDB debugging is available by those data. (Though if the bug happens at very delicate timing, it might prevent the bug from happening again.) -Adding some printfs in tcp_output.c:tcp_setpersist() panic case might be useful. Thanks, Yoshinobu Inoue To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000221212656L.shin>