Date: Thu, 10 Oct 2002 15:50:47 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: abe <abe@informationwave.net> Cc: hackers@freebsd.org Subject: Re: fatal trap 12 kernel panic Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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". > > 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. > > 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 ...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 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?3DA60447.4C66C85>