Date: Thu, 16 May 2002 18:20:57 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Dag-Erling Smorgrav <des@ofug.org>, <alpha@FreeBSD.ORG>, <current@FreeBSD.ORG> Subject: Re: loader failure Message-ID: <20020516175948.B1999-100000@gamplex.bde.org> In-Reply-To: <XFMail.20020515171714.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 15 May 2002, John Baldwin wrote: > On 15-May-2002 Dag-Erling Smorgrav wrote: > > John Baldwin <jhb@FreeBSD.org> writes: > >> The kernel overflowed it's stack. In SRM, you can try to debug this > >> by using 'e sp' to get the stack pointer then get a stack dump and save > >> a copy of it in a log or something, reboot the machine, then use gdb's > >> list command on the kernel.debug to figure out the source:line for all > >> the kernel-text addresses in the stack dump to figure out the backtrace. > > > > How do I get a stack trace? I can't get the 'examine' command to > > actually print anything... > > It depends on which machine actually. :-/ First do 'e sp' to get the > stack pointer. Then you want to do something like this: > > e -n 100 <value of sp without any leading 0x> At least for i386's, it can be useful to set $esp and $eip to non-preposterous values if they are hosed (record the old values first). Bugs in the pagefault handler make the behaviour for invalid pointers very bad. The main one trap_pfault() doesn't give up immediately if the pagefault is from within ddb. In old versions of FreeBSD, this is probably only fatal if trap_pfault() blocks, but in -current is is fatal in the usual case where trap_fault() acquires a sleep lock. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020516175948.B1999-100000>