Date: Sat, 15 May 1999 20:18:33 -0700 From: Mike Smith <mike@smith.net.au> To: Kevin Day <toasty@home.dragondata.com> Cc: current@freebsd.org Subject: Re: -current page fault at 0xdeadc0de Message-ID: <199905160318.UAA03441@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 12 May 1999 21:58:59 CDT." <199905130258.VAA11540@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>
>
> I had two systems reboot at nearly the same time. (30 seconds apart), and
> are completely unrelated.
These both look like stack damage, actually.
> One system was running 2.2.8, and my core file presents me with this:
>
> su-2.02# gdb -k
> GDB is free software and you are welcome to distribute copies of it
> under certain conditions; type "show copying" to see the conditions.
> There is absolutely no warranty for GDB; type "show warranty" for details.
> GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation,
> Inc.
> (kgdb) exec-file kernel.0
> (kgdb) symbol-file kernel.0.debug
> Reading symbols from kernel.0.debug...done.
> (kgdb) core-file vmcore.0
> IdlePTD 24a000
> current pcb at 202bfc
> #0 0x14 in ?? ()
> (kgdb) bt
> #0 0x14 in ?? ()
> #1 0x34000004 in ?? ()
> Cannot access memory at address 0x7205c76a.
>
> Were things just trashed, or am I doing something wrong?
Looks like a return from a function that's destroyed the stack.
>
> The other system was running -current, and gives me:
...
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0xdeadc0de
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xdeadc0de
Jump through vector in freed memory; someone has freed a region of
memory and is still using it, or has freed a region of memory that was
never obtained by malloc.
> panic: page fault
> syncing disks...
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0xdeadc126
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc018e3d8
Whoops. You need DDB to track this; you're only going to get the trace
for the second fault with gdb, which won't be at all illuminating I
don't think.
...
> #0 boot (howto=260) at ../../kern/kern_shutdown.c:288
> 288 dumppcb.pcb_cr3 = rcr3();
> (kgdb) bt
> #0 boot (howto=260) at ../../kern/kern_shutdown.c:288
> #1 0xc0145755 in panic () at ../../kern/kern_shutdown.c:450
> #2 0xc020e9e2 in trap_fatal (frame=0xcb4ad8dc, eva=3735929126)
> at ../../i386/i386/trap.c:917
> #3 0xc020e695 in trap_pfault (frame=0xcb4ad8dc, usermode=0, eva=3735929126)
> at ../../i386/i386/trap.c:810
> #4 0xc020e2d7 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi =
> 0,
> tf_esi = 0, tf_ebp = -884287172, tf_isp = -884287224, tf_ebx = 16384,
> tf_edx = -559038242, tf_ecx = -1059309536, tf_eax = -1053816960,
> tf_trapno = 12, tf_err = 0, tf_eip = -1072110632, tf_cs = 8,
> tf_eflags = 66182, tf_esp = -1062703744, tf_ss = -911937724})
> at ../../i386/i386/trap.c:436
> (kgdb)
Nope, not useful at all really. Look at the first trap message to see
where the first one occurred, that'll at least give you a locality.
Just out of curiosity, are either of these systems running with NCR
controllers?
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ mike@smith.net.au
\\ The race is long, and in the \\ msmith@freebsd.org
\\ end it's only with yourself. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905160318.UAA03441>