RE: 6.3-RELEASE panic
Hi all,
I've encountered the panic on 6.3-RELEASE once again - this time with
prepared debug kernel, so here you go. It seems like the panic is usually
initiated when firefox exits. Let me know if any further information is
Petr
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or 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.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x9ef418
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc07f2348
stack pointer = 0x28:0xea61cb08
frame pointer = 0x28:0xea61cb14
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1808 (firefox-bin)
trap number = 12
panic: page fault
Uptime: 4d23h12m54s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261760 pages) 1007 991 975 959 943 927 911 895 879 863
847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575
(CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) 559 543 527 511 495
479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191
175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc06a4ad6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc06a4d6c in panic (fmt=0xc096ba63 "%s")
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc090d0d4 in trap_fatal (frame=0xea61cac8, eva=10417176)
at /usr/src/sys/i386/i386/trap.c:838
#4 0xc090ce3b in trap_pfault (frame=0xea61cac8, usermode=0, eva=10417176)
at /usr/src/sys/i386/i386/trap.c:745
#5 0xc090ca79 in trap (frame=
{tf_fs = -1066532856, tf_es = -648871896, tf_ds = -949551064, tf_edi =
2590720, tf_esi = 0, tf_ebp = -362689772, tf_isp = -362689804, tf_ebx = 0,
tf_edx = 2590720, tf_ecx = 10417152, tf_eax = -981897076, tf_trapno = 12,
tf_err = 0, tf_eip = -1065409720, tf_cs = 32, tf_eflags = 2163206, tf_esp =
-981897076, tf_ss = 132}) at /usr/src/sys/i386/i386/trap.c:435
#6 0xc08f9f0a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc07f2348 in pagedep_find (pagedephd=0xc579708c, ino=2590720, lbn=)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:1165
#8 0xc07f23ea in pagedep_lookup (ip=0xc771f7bc, lbn=0, flags=1,
pagedeppp=0xea61cb64) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1204
#9 0xc07f620b in newdirrem (bp=0xd953e678, dp=0xc771f7bc, ip=0xc6736084,
isrmdir=0, prevdirremp=0xea61cb90)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:3301
#10 0xc07f5fc0 in softdep_setup_remove (bp=0xd953e678, dp=0xc771f7bc,
ip=0xc6736084, isrmdir=0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3230
#11 0xc0806bb6 in ufs_dirremove (dvp=0xc719b440, ip=0xc6736084,
flags=83918860, isrmdir=0) at /usr/src/sys/ufs/ufs/ufs_lookup.c:1020
#12 0xc0809b93 in ufs_remove (ap=0x278800)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:798
#13 0xc091e8b0 in VOP_REMOVE_APV (vop=0xc579708c, a=0xea61cc3c)
at vnode_if.c:1077
#14 0xc070401f in kern_unlink (td=0xc7678480,
path=0xbc29288 , pathseg=UIO_USERSPACE)
at vnode_if.h:563
#15 0xc0703e8e in unlink (td=0xc7678480, uap=0xc579708c)
at /usr/src/sys/kern/vfs_syscalls.c:1642
#16 0xc090d3eb in syscall (frame=
{tf_fs = 134611003, tf_es = 134742075, tf_ds = -1078001605, tf_edi =
197300736, tf_esi = 17, tf_ebp = -1077950232, tf_isp = -362689180, tf_ebx =
673223176, tf_edx = 197300736, tf_ecx = 197300736, tf_eax = 10, tf_trapno =
0, tf_err = 2, tf_eip = 684230759, tf_cs = 51, tf_eflags = 2097810, tf_esp =
-1077950388, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984
#17 0xc08f9f5f in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:200
#18 0x0033 in ?? ()
(kgdb) bt full
#0 doadump () at pcpu.h:165
No locals.
#1 0xc06a4ad6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
first_buf_printf = 1
#2 0xc06a4d6c in panic (fmt=0xc096ba63 "%s")
at /usr/src/sys/kern/kern_shutdown.c:565
td = (struct thread *) 0xc7678480
bootopt = 260
newpanic = 0
ap = 0xc7678480 "0t%ČŕzĺĹ\200'[EMAIL PROTECTED]'`ÇězĺĹ"
buf = "page fault", '\0'
#3 0xc090d0d4 in trap_fatal (frame=0xea61cac8, eva=10417176)
at /usr/src/sys/i386/i386/trap.c:838
code = 40
ss = 40
esp = 0
type = 12
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27,
ssd_dpl = 0, ssd_p = 1, ssd_xx = 4, ssd_xx1 = 3, ssd_def32 = 1,
ssd_gran = 1}
msg = 0x0
#4 0xc090ce3b in trap_pfault (frame=0xea61cac8, use
Re: 6.3-RELEASE panic
On January 23, 2008, John Baldwin wrote: > On Monday 21 January 2008 04:51:54 pm Kris Kennaway wrote: > > Petr Holub wrote: > > > Hi, > > > > > > I've just updated the 6.2-RELEASE to 6.3-RELEASE using freebsd-update > > > as described in daemonology blog. > > > > > > While removing the old packages using > > > pkg_delete -af > > > I've tried to stop all the deamons from /usr/local/etc/rc.d and > > > got the following panic (hand transcribed from a photo - I don't have > > > that machine enabled for remote debugging). Panic seems to be > > > deterministic when stopping those scripts (verified by subsequent > > > attempts while pkg_delete was not running). > > > > > > (kgdb) bt > > > #0 0xc06a46a6 in doadump () > > > #1 0xc06a4b76 in boot () > > > #2 0xc06a4e0c in panic () > > > #3 0xc090d1b4 in trap_fatal () > > > #4 0xc090cf1b in trap_pfault () > > > #5 0xc090cb59 in trap () > > > #6 0xc08f9fea in calltrap () > > > #7 0xc073fa6f in in_delmulti () > > > #8 0xc0748e15 in ip_freemoptions () > > > #9 0xc07414cc in in_pcbdetach () > > > #10 0xc075a0ee in udp_detach () > > > #11 0xc06de0b8 in soclose () > > > #12 0xc06cd83b in soo_close () > > > #13 0xc0683ffc in fdrop_locked () > > > #14 0xc0683f25 in fdrop () > > > #15 0xc0682553 in closef () > > > #16 0xc067f8e7 in kern_close () > > > #17 0xc067f6d8 in close () > > > #18 0xc090d4cb in syscall () > > > #19 0xc08fa03f in Xint0x80_syscall () > > > #20 0x0033 in ?? () > > > Previous frame inner to this frame (corrupt stack?) > > > > Can you obtain a trace against the kernel.symbols? > > I've been seeing this panic (and several variations of) for quite a while > on 6.x. It appears that a socket is being double-closed somehow. I > usually see it during exit1() when a process' file descriptor table is > being freed. I've spent a lot of time looking for a fd reference count > leak or some such but haven't found one yet. :( I've also seen panics > with vnodes having a ref cnt underflow in vrele or vput, so I've wondered > if it's a fd-level bug that affects both vnodes and sockets rather than > separate socket and vnode bugs. For comparison, here is the callstack from the panic reported in kern/116077. The PR has symbolic information. #0 doadump () #1 0xc055293e in boot #2 0xc0552c95 in panic #3 0xc06e6232 in trap_fatal #4 0xc06e5f3b in trap_pfault #5 0xc06e5b51 in trap #6 0xc06d0b1a in calltrap () #7 0xc05e3e6f in in_delmulti #8 0xc05ed8e9 in ip_freemoptions #9 0xc05e5d6c in in_pcbdetach #10 0xc05fee96 in udp_detach #11 0xc058e710 in soclose #12 0xc057db3f in soo_close #13 0xc052fd9c in fdrop_locked #14 0xc052fcc5 in fdrop #15 0xc052e263 in closef #16 0xc052d253 in fdfree #17 0xc0536b4b in exit1 #18 0xc05366b0 in sys_exit #19 0xc06e6577 in syscall #20 0xc06d0b6f in Xint0x80_syscall () #21 0x0033 in ?? () It is also triggered when a multi-cast client shuts down. The patch in the PR fixes this issue for me. I have been running with it since November. Cheers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
On Tuesday 22 January 2008 05:27:36 am Petr Holub wrote: > > > I thought we shipped the debugging symbols in /boot precisely for the > > > reason of making panics with default installs not report useless traces > :( > > > > I think building GENERIC kernel from sources with > > tag=RELENG_6_3_0_RELEASE will help. > > I tried to build it from the sources that come from the freebsd-update > and thus I assume they are actually RELENG_6_3_0_RELEASE. Still I was > unable to run gdb with the given vmcore against such a kernel. You will need to build a debug kernel and reproduce the panic and use kgdb on the new crash with the new kernel. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
On Monday 21 January 2008 07:13:26 pm Kris Kennaway wrote: > Colin Percival wrote: > > Kris Kennaway wrote: > >> Petr Holub wrote: > >>> as I've said in my previous email (outside the list), I've got the > >>> kernel through freebsd-update and it seems there is no kernel.debug > >>> nor kernel.symbols present. Would it be possible to get the .symbols > >>> or .debug for that kernel? (See my previuous email with more detailed > >>> info). > >> Ah, I missed that, sorry. Colin hopefully will have the kernel.debug > >> handy. > > > > I'm afraid not -- FreeBSD Update is just distributing the bits from the > > release ISO image, and the release ISO doesn't include kernel debug bits > > (at least, not on 6.3-RELEASE -- I think it does on 7.0-RC1). > > I thought we shipped the debugging symbols in /boot precisely for the > reason of making panics with default installs not report useless traces :( In the past re@ has removed the 'makeoptions DEBUG=-g' from GENERIC when making a stable branch. 6.x doesn't have the foo.symbols changes in it either. It's too late for 6.3, but we should make sure 7.0 has symbols enabled by default still. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
On Monday 21 January 2008 04:51:54 pm Kris Kennaway wrote: > Petr Holub wrote: > > Hi, > > > > I've just updated the 6.2-RELEASE to 6.3-RELEASE using freebsd-update > > as described in daemonology blog. > > > > While removing the old packages using > > pkg_delete -af > > I've tried to stop all the deamons from /usr/local/etc/rc.d and > > got the following panic (hand transcribed from a photo - I don't have that > > machine enabled for remote debugging). Panic seems to be deterministic > > when stopping those scripts (verified by subsequent attempts while > > pkg_delete was not running). > > > (kgdb) bt > > #0 0xc06a46a6 in doadump () > > #1 0xc06a4b76 in boot () > > #2 0xc06a4e0c in panic () > > #3 0xc090d1b4 in trap_fatal () > > #4 0xc090cf1b in trap_pfault () > > #5 0xc090cb59 in trap () > > #6 0xc08f9fea in calltrap () > > #7 0xc073fa6f in in_delmulti () > > #8 0xc0748e15 in ip_freemoptions () > > #9 0xc07414cc in in_pcbdetach () > > #10 0xc075a0ee in udp_detach () > > #11 0xc06de0b8 in soclose () > > #12 0xc06cd83b in soo_close () > > #13 0xc0683ffc in fdrop_locked () > > #14 0xc0683f25 in fdrop () > > #15 0xc0682553 in closef () > > #16 0xc067f8e7 in kern_close () > > #17 0xc067f6d8 in close () > > #18 0xc090d4cb in syscall () > > #19 0xc08fa03f in Xint0x80_syscall () > > #20 0x0033 in ?? () > > Previous frame inner to this frame (corrupt stack?) > > Can you obtain a trace against the kernel.symbols? I've been seeing this panic (and several variations of) for quite a while on 6.x. It appears that a socket is being double-closed somehow. I usually see it during exit1() when a process' file descriptor table is being freed. I've spent a lot of time looking for a fd reference count leak or some such but haven't found one yet. :( I've also seen panics with vnodes having a ref cnt underflow in vrele or vput, so I've wondered if it's a fd-level bug that affects both vnodes and sockets rather than separate socket and vnode bugs. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
Petr Holub wrote: I tried to build it from the sources that come from the freebsd-update and thus I assume they are actually RELENG_6_3_0_RELEASE. Still I was unable to run gdb with the given vmcore against such a kernel. How do you did that? Try the following commands: # cd /usr/src/ # make buildkernel # cd /var/crash # gdb /usr/obj/usr/src/sys/GENERIC/kernel.debug ./vmcore.0 |tee bt.txt (gdb) bt (gdb) bt full (gdb) q and show your /var/crash/bt.txt file. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: 6.3-RELEASE panic
> > I thought we shipped the debugging symbols in /boot precisely for the > > reason of making panics with default installs not report useless traces :( > > I think building GENERIC kernel from sources with > tag=RELENG_6_3_0_RELEASE will help. I tried to build it from the sources that come from the freebsd-update and thus I assume they are actually RELENG_6_3_0_RELEASE. Still I was unable to run gdb with the given vmcore against such a kernel. Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
Kris Kennaway wrote: I'm afraid not -- FreeBSD Update is just distributing the bits from the release ISO image, and the release ISO doesn't include kernel debug bits (at least, not on 6.3-RELEASE -- I think it does on 7.0-RC1). I thought we shipped the debugging symbols in /boot precisely for the reason of making panics with default installs not report useless traces :( I think building GENERIC kernel from sources with tag=RELENG_6_3_0_RELEASE will help. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: 6.3-RELEASE panic
> > I'm afraid not -- FreeBSD Update is just distributing the bits from the > > release ISO image, and the release ISO doesn't include kernel debug bits > > (at least, not on 6.3-RELEASE -- I think it does on 7.0-RC1). > > I thought we shipped the debugging symbols in /boot precisely for the > reason of making panics with default installs not report useless traces :( If you can build it ex post, I will be more than happy to send you the trace back. Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
On January 21, 2008, Petr Holub wrote: > Hi, > > I've just updated the 6.2-RELEASE to 6.3-RELEASE using freebsd-update > as described in daemonology blog. > > While removing the old packages using > pkg_delete -af > I've tried to stop all the deamons from /usr/local/etc/rc.d and > got the following panic (hand transcribed from a photo - I don't have that > machine enabled for remote debugging). Panic seems to be deterministic > when stopping those scripts (verified by subsequent attempts while > pkg_delete was not running). > > Stopping mdnsd. Possibly it is related to http://www.freebsd.org/cgi/query-pr.cgi?pr=116077 That particular problem manifests itself under similar circumstances and the callstack looks similar too. Jerry Toung's patch in the PR fixes things for me. Cheers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
Colin Percival wrote: Kris Kennaway wrote: Petr Holub wrote: as I've said in my previous email (outside the list), I've got the kernel through freebsd-update and it seems there is no kernel.debug nor kernel.symbols present. Would it be possible to get the .symbols or .debug for that kernel? (See my previuous email with more detailed info). Ah, I missed that, sorry. Colin hopefully will have the kernel.debug handy. I'm afraid not -- FreeBSD Update is just distributing the bits from the release ISO image, and the release ISO doesn't include kernel debug bits (at least, not on 6.3-RELEASE -- I think it does on 7.0-RC1). I thought we shipped the debugging symbols in /boot precisely for the reason of making panics with default installs not report useless traces :( Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
Kris Kennaway wrote: > Petr Holub wrote: >> as I've said in my previous email (outside the list), I've got the >> kernel through freebsd-update and it seems there is no kernel.debug >> nor kernel.symbols present. Would it be possible to get the .symbols >> or .debug for that kernel? (See my previuous email with more detailed >> info). > > Ah, I missed that, sorry. Colin hopefully will have the kernel.debug > handy. I'm afraid not -- FreeBSD Update is just distributing the bits from the release ISO image, and the release ISO doesn't include kernel debug bits (at least, not on 6.3-RELEASE -- I think it does on 7.0-RC1). Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
Petr Holub wrote: Kris, Yes, the kernel.debug or kernel.symbols should either be in your /boot/kernel or in your kernel compile directory (unless you built your kernel without -g, but I think it is on by default). as I've said in my previous email (outside the list), I've got the kernel through freebsd-update and it seems there is no kernel.debug nor kernel.symbols present. Would it be possible to get the .symbols or .debug for that kernel? (See my previuous email with more detailed info). Ah, I missed that, sorry. Colin hopefully will have the kernel.debug handy. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: 6.3-RELEASE panic
Kris, > Yes, the kernel.debug or kernel.symbols should either be in your > /boot/kernel or in your kernel compile directory (unless you built your > kernel without -g, but I think it is on by default). as I've said in my previous email (outside the list), I've got the kernel through freebsd-update and it seems there is no kernel.debug nor kernel.symbols present. Would it be possible to get the .symbols or .debug for that kernel? (See my previuous email with more detailed info). Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
Petr Holub wrote: Can you obtain a trace against the kernel.symbols? Is it possible to do it with this vmcore? Petr Yes, the kernel.debug or kernel.symbols should either be in your /boot/kernel or in your kernel compile directory (unless you built your kernel without -g, but I think it is on by default). Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: 6.3-RELEASE panic
> Can you obtain a trace against the kernel.symbols? Is it possible to do it with this vmcore? Petr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.3-RELEASE panic
Petr Holub wrote: Hi, I've just updated the 6.2-RELEASE to 6.3-RELEASE using freebsd-update as described in daemonology blog. While removing the old packages using pkg_delete -af I've tried to stop all the deamons from /usr/local/etc/rc.d and got the following panic (hand transcribed from a photo - I don't have that machine enabled for remote debugging). Panic seems to be deterministic when stopping those scripts (verified by subsequent attempts while pkg_delete was not running). (kgdb) bt #0 0xc06a46a6 in doadump () #1 0xc06a4b76 in boot () #2 0xc06a4e0c in panic () #3 0xc090d1b4 in trap_fatal () #4 0xc090cf1b in trap_pfault () #5 0xc090cb59 in trap () #6 0xc08f9fea in calltrap () #7 0xc073fa6f in in_delmulti () #8 0xc0748e15 in ip_freemoptions () #9 0xc07414cc in in_pcbdetach () #10 0xc075a0ee in udp_detach () #11 0xc06de0b8 in soclose () #12 0xc06cd83b in soo_close () #13 0xc0683ffc in fdrop_locked () #14 0xc0683f25 in fdrop () #15 0xc0682553 in closef () #16 0xc067f8e7 in kern_close () #17 0xc067f6d8 in close () #18 0xc090d4cb in syscall () #19 0xc08fa03f in Xint0x80_syscall () #20 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) Can you obtain a trace against the kernel.symbols? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.3-RELEASE panic
Hi, I've just updated the 6.2-RELEASE to 6.3-RELEASE using freebsd-update as described in daemonology blog. While removing the old packages using pkg_delete -af I've tried to stop all the deamons from /usr/local/etc/rc.d and got the following panic (hand transcribed from a photo - I don't have that machine enabled for remote debugging). Panic seems to be deterministic when stopping those scripts (verified by subsequent attempts while pkg_delete was not running). Stopping mdnsd. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x5a fault code = supervisor read, page ont present instruction pointer = 0x20:0xc073fa6f stack pointer = 0x28:0xe625db9c frame pointer = 0x28:0xe625dba4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1177 (mdnsd) trap number = 12 panic: page fault [root@ /var/crash]# cat info.10 Dump header from device /dev/ad4s1b Architecture: i386 Architecture Version: 2 Dump Length: 1072824320B (1023 MB) Blocksize: 512 Dumptime: Mon Jan 21 17:26:26 2008 Hostname: evenstar.ics.muni.cz Magic: FreeBSD Kernel Dump Version String: FreeBSD 6.3-RELEASE #0: Wed Jan 16 04:18:52 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Panic String: page fault Dump Parity: 2784976745 Bounds: 10 Dump Status: good [root@ /var/crash]# kgdb /boot/kernel/kernel vmcore.10 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or 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. This GDB was configured as "i386-marcel-freebsd". (no debugging symbols found)...Attempt to extract a component of a value that is not a structure pointer. (kgdb) bt #0 0xc06a46a6 in doadump () #1 0xc06a4b76 in boot () #2 0xc06a4e0c in panic () #3 0xc090d1b4 in trap_fatal () #4 0xc090cf1b in trap_pfault () #5 0xc090cb59 in trap () #6 0xc08f9fea in calltrap () #7 0xc073fa6f in in_delmulti () #8 0xc0748e15 in ip_freemoptions () #9 0xc07414cc in in_pcbdetach () #10 0xc075a0ee in udp_detach () #11 0xc06de0b8 in soclose () #12 0xc06cd83b in soo_close () #13 0xc0683ffc in fdrop_locked () #14 0xc0683f25 in fdrop () #15 0xc0682553 in closef () #16 0xc067f8e7 in kern_close () #17 0xc067f6d8 in close () #18 0xc090d4cb in syscall () #19 0xc08fa03f in Xint0x80_syscall () #20 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) Petr PS: please cc me in the replies as I'm not regular subscribed to the stable@ list. Thanks a lot. Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-549493944 fax: +420-541212747 e-mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
