On Thu, 23 Nov 2000, FengYue wrote:
->dmesg: kvm_read:
->---
->#6 0xc01882dd in fr_makefrip (hlen=20, ip=0xc0a48fe4, fin=0xd892fb0c)
-> at ../../netinet/fil.c:258
->#7 0xc018e20c in fr_checkicmpmatchingstate (ip=0xc0a48fc8,
->fin=0xd892fc1c)
-> at ../../netinet/ip_state.c:1081
Hi, I'm looking at ip_state.c and fr_makefrip.c, there is one thing
I don't quiet understand and see if any of you could explain a bit to me:
in ip_state.c:973, it declares fr_info_t ofin on the function stack --
apearly uninit'ed, then at line 1081 it calls
fr_makefrip(...,...,&ofin); (ofin is not init'ed in anyway before calling
fr_makefrip() at line 1081)
in fil.c:202, fr_makefrip(), it does some assignments to elements in *fin
which points to &ofin in ip_state.c:1081, anyway, fin is not init'ed and
later in fr_makefrip():227 it checks for fin->fin_v which contains the
IP version, obviously I think fin->fin_v is some garbage at this point
and if it happened to have value '6' in fin_v, then V6 code will be
executed and thus would cause a panic at line fil.c:258 just like what
shows in the GDB trace.
Did I find the bug causing the panic or did I miss something?
As I mentioned in my previous E-mail, a machine of mine crashed 10 hours
after upgrading to 4.2-stable. After the crash I commented out an
IPFW ruleset which basically allows icmp type 0 & 11 to be in, until
now the machine has not experienced a panic.
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
