Skip site navigation (1)Skip section navigation (2)
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>