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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
