Date: Thu, 10 Oct 2002 19:24:16 -0400 From: abe <abe@informationwave.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: hackers@freebsd.org Subject: Re: fatal trap 12 kernel panic Message-ID: <20021010232416.GA97757@dipole.informationwave.net> In-Reply-To: <3DA60447.4C66C85@mindspring.com> References: <20021010212954.GA67855@dipole.informationwave.net> <3DA5F3BC.CD0154CF@mindspring.com> <20021010214518.GB71656@dipole.informationwave.net> <3DA5FCD2.B23CD912@mindspring.com> <20021010222545.GA82461@dipole.informationwave.net> <3DA60447.4C66C85@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 10, 2002 at 03:50:47PM -0700, Terry Lambert wrote: > abe wrote: > > > You have a traceback; do you have a system dump? > > > > Sorry Terry, unfortunately it wouldn't produce a system dump unless > > I was not taking the proper steps to produce one. Any URL that would > > point this out to me or any suggestion? > > Poul changed this code. I haven't been able to get a correct dump > locally since then. It would really depend on the *exact* version > of FreeBSD you are running. You might want to look in the handbook, > if you have a good version. > > The normal way on older versions was to add: > > dumpdev="/dev/ad0s3b" > > ...or whatever device your swap normally lives on... to your > /etc/rc.conf. It's required to be the size of physical memory > plus 64K (at a minimum). See "man dumpon". Tried that, no luck. savecore still complained about no dumpdev. 4.5-release I'd imagine is the exact version... > > > > > Knowing the line of C code involved would be much more useful. > > > > > > Are you suddenly running an application that you did not formerly > > > run? The creation of a dynamic rule as a result of a ip_output() > > > call to ip_fw_chk() to install_state() to add_dyn_rule() implies > > > that the flow ID passed down to add_dyn_rule() with the value of > > > dyn_type == DYN_KEEP_STATE is valid. > > > > This is a vanilla installation with pretty much all inet services > > disabled. > > You are doing something UDP. It may be that some idiot has > configured your machine as their DNS forwarder. This can > happen if you leave your DNS server open for forwarding requests. Using at the moment comcast's nameservers, and an IP issued via DHCP from them. > > > > > One possibility that occurs to me is that you end up with a > > > parent count going over 65535 (it's a u_int16_t). When it is > > > counted yet again, it goes to 0, then again, to 1. Then the > > > next reference deletion causes it to go 1->0, at which point, > > > the parent is deleted, even though it's still referenced. > > > > > > If this is the case, you can work around it by ensuring that a > > > dynamic limit of 65534 or less is set. > > > > > > Another workaround would be to change the "count" member of the > > > "struct ipfw_dyn_rule" to b a u_int32_t, and recompile everything. > > > > > > > > > Without knowing the source code involved, you are unlikely to get > > > an answer that's more than a guess. 8-(. > > > > Hell, it's more than I've gotten thus far. Much appreciation. > > No problem. > > Thinking a bit more: > > You should be able to find out the C code at assembly code offset > 0x172, assuming you created your kernel with "config -g", and you > compiled the ipfw statically into the kernel, instead of loading > it as a module. > > Assuming this is the case, to do that, go to the directory you > compiled the kernel in, and run: > > gdb -k kernel.debug > list *add_dyn_rule+0x172 (kgdb) list *add_dyn_rule+0x172 No source file for address 0xc021e5d6 (kgdb) > > ...don't forget to insert the 'x': it's a hex number. The kernel > debugger leaves out the 'x' "To Be A Pain In Terry's Ass, For No > Good Reason"(tm) ...you'll notice that it didn't leave it out of the > traceback itself. > > You will likely need to back the number up to get a clean listing > of the source line that caused the fault. > > Yeah, statically compiling in the IPFW is annoying, particularly > since you will have to play "swap the kernel" to get a kernel up > without IPFW, and this will be a pain, if the panic is immediate. > > -- Terry Regards, Abe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021010232416.GA97757>