Date: Mon, 28 Apr 1997 11:04:43 -0700 From: Julian Elischer <julian@whistle.com> To: Simon Shapiro <Shimon@i-Connect.Net> Cc: freebsd-hackers@freebsd.org Subject: Re: A Desparate Plea for Help... Message-ID: <3364E6BB.41C67EA6@whistle.com> References: <XFMail.970427164721.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
Simon Shapiro wrote: > > hi Y'all, > > > The last and most troubling problem is a complete crash/freeze when running > certain X11 applications; At ONE point, we managed to observe a panic that > went something like: > > Fata trap 12 page fault at 0xf71e0014 > > _spec_open+0x6e > _vm_open > _open > _syscall > _Xsyscall > > There was a mention of bash in this panic. The best thing for you to do with this is to compile the gernet using -g do this by using config -g do: (on the compile machine) make cp kernel kernel.debug strip -d kernel also: cat >.gdbinit <<DONE set remotebaud 9600 file kernel.debug target remote /dev/cuaa1 DONE compile the options DDB and set the default debugger to be gdb by booting with -g then if you get a crash, make sure that /dev/cuaa1 (com2) on your source machine is connected to com1 on the victim machine and type cd /sys/compile/<MYKENREL> gdb this (due to the .gdbinit) will fire up gdb and allow you to walk up and down the stack trace of the crashed kernel. even if the screen is stuck in X11. there are some problems I've seen. 1/ the newest gdb versions are not as good at doing this as some of the older ones. and sometimes get confused. 2/ you must remember to make sure the system has sert gdb to be the kernel debugger. (there may be a compile time option for this.. I forget) 3/ some uarts don't like this if com1 is already being used for something.. (move your mouse to com2) julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3364E6BB.41C67EA6>