Today my system coredumped (4.8-STABLE from Saturday), I believe it's
somehow
X11 related:
X11 crashed first (signal 11). I was running it as root (I know I
shouldn't).
I didn't think about it and restarted X11. While it was starting, I had a
look
at the console, there was a bright white message: issignal.
This shows up at X11 startup.
Then the system coredumped.
Below is more information. Is this a serious problem?
Please help me, I'm an inexperienced programmer and I can't do this
alone.
Daniela
# gdb -k kernel.debug vmcore.0
...
IdlePTD at phsyical address 0x005ba000
initial pcb at physical address 0x004d3100
panicstr: ufsdirhash_lookup: bad offset in hash array
panic messages:
---
panic: ufsdirhash_lookup: bad offset in hash array
syncing disks... 80 2 1
done
Uptime: 1d21h53m1s
/dev/vmmon: Module vmmon: unloaded
dumping to dev #ad/0x30001, offset 1048704
dump ata0: resetting devices .. done
511 ... 0
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc021f00b in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
#2 0xc021f449 in panic (
fmt=0xc0433ba0 "ufsdirhash_lookup: bad offset in hash array")
at /usr/src/sys/kern/kern_shutdown.c:595
#3 0xc033b1d3 in ufsdirhash_lookup (ip=0xc262eb00,
name=0xd804c427
"kufacts.cc.ukans.edu_ftp_pub_history_Europe_Medieval_aids_FFFFFF_4dbcef50",
namelen=73, offp=0xc262eb64, bpp=0xd8d2ecbc, prevoffp=0x0)
at /usr/src/sys/ufs/ufs/ufs_dirhash.c:361
#4 0xc033589d in ufs_lookup (ap=0xd8d2ed18)
at /usr/src/sys/ufs/ufs/ufs_lookup.c:212
#5 0xc033aa31 in ufs_vnoperate (ap=0xd8d2ed18)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2376
#6 0xc0248a8e in vfs_cache_lookup (ap=0xd8d2ed70) at vnode_if.h:77
#7 0xc033aa31 in ufs_vnoperate (ap=0xd8d2ed70)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2376
#8 0xc024b9f9 in lookup (ndp=0xd8d2eec8) at vnode_if.h:52
#9 0xc024b4f4 in namei (ndp=0xd8d2eec8) at /usr/src/sys/kern/vfs_lookup.c:153
#10 0xc0253f3f in vn_open (ndp=0xd8d2eec8, fmode=1, cmode=0)
at /usr/src/sys/kern/vfs_vnops.c:138
#11 0xc0250074 in open (p=0xd8b87f20, uap=0xd8d2ef80)
at /usr/src/sys/kern/vfs_syscalls.c:1029
#12 0xc03c25b5 in syscall2 (frame={tf_fs = 134676527, tf_es = 47,
---Type <return> to continue, or q <return> to quit---
tf_ds = -1078001617, tf_edi = 4, tf_esi = 686954328,
tf_ebp = -1077941708, tf_isp = -657264684, tf_ebx = 686871084,
tf_edx = 0, tf_ecx = 15, tf_eax = 5, tf_trapno = 12, tf_err = 2,
tf_eip = 686596376, tf_cs = 31, tf_eflags = 663, tf_esp = -1077941752,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1175
#13 0xc03b30a5 in Xint0x80_syscall ()
#14 0x28ee321f in ?? ()
#15 0x2920f154 in ?? ()
#16 0x292036ea in ?? ()
#17 0x291fbd7d in ?? ()
#18 0x291fbc8f in ?? ()
#19 0x29200061 in ?? ()
#20 0x281b434b in ?? ()
#21 0x281b05e4 in ?? ()
#22 0x291f9d97 in ?? ()
#23 0x804ccba in ?? ()
#24 0x804d9c0 in ?? ()
#25 0x804de1c in ?? ()
#26 0x804ec0e in ?? ()
#27 0x804b42e in ?? ()
In message <200306232314.02175.dgw@liwest.at>, Daniela <dgw@liwest.at> writes>Today my system coredumped (4.8-STABLE from Saturday), I believe it's somehow >X11 related:I just updated my system to RELENG_4 from Tuesday morning, and saw a crash as X started. Unfortunately, It was a remote restart, so I had to win a race to move xdm out of the way before the system crashed ;) Fatal trap 12: page fault while in kernel mode fault virtual address = 0xb0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc1abe290 stack pointer = 0x10:0xd360ed40 frame pointer = 0x10:0xd360ed6c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 3 current process = 289 (XFree86) interrupt mask = none trap number = 12 panic: page fault (kgdb) bt #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc0185a3c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc0185e70 in poweroff_wait (junk=0xc02f610c, howto=-1070638065) at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc02a9e53 in trap_fatal (frame=0xd360ed00, eva=176) at /usr/src/sys/i386/i386/trap.c:974 #4 0xc02a9b0d in trap_pfault (frame=0xd360ed00, usermode=0, eva=176) at /usr/src/sys/i386/i386/trap.c:867 #5 0xc02a96e3 in trap (frame={tf_fs = -1045757936, tf_es = -748683248, tf_ds = -1045692400, tf_edi = 0, tf_esi = -1045415936, tf_ebp = -748622484, tf_isp = -748622548, tf_ebx = 0, tf_edx = 143587328, tf_ecx = -1047585952, tf_eax = -1045421312, tf_trapno = 12, tf_err = 0, tf_eip = -1045699952, tf_cs = 8, tf_eflags = 78470, tf_esp = -1045733376, tf_ss = -1045660664}) at /usr/src/sys/i386/i386/trap.c:466 #6 0xc1abe290 in ?? () #7 0xc1abfa88 in ?? () #8 0xc01bfc3c in spec_ioctl (ap=0xd360edf0) at /usr/src/sys/miscfs/specfs/spec_vnops.c:306 #9 0xc01bf94d in spec_vnoperate (ap=0xd360edf0) at /usr/src/sys/miscfs/specfs/spec_vnops.c:119 #10 0xc0241b09 in ufs_vnoperatespec (ap=0xd360edf0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2394 #11 0xc01bc0af in vn_ioctl (fp=0xc1a52b80, com=3222037529, data=0xd360eeb4 "\200", p=0xd3596a80) at vnode_if.h:429 #12 0xc01956da in ioctl (p=0xd3596a80, uap=0xd360ef80) at /usr/src/sys/sys/file.h:178 #13 0xc02aa0b9 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 143392256, tf_esi = 143392256, tf_ebp = -1077937296, tf_isp = -748621868, tf_ebx = 7, tf_edx = 0, tf_ecx = 0, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 673282704, tf_cs = 31, tf_eflags = 12947, tf_esp = -1077937340, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1175 #14 0xc029db75 in Xint0x80_syscall () #15 0x8500f0b in ?? () #16 0x879ec43 in ?? () #17 0x879f325 in ?? () #18 0x8781e0d in ?? () #19 0x80bfd46 in ?? () #20 0x806c1ad in ?? () #21 0x80bf3be in ?? () #22 0x806b21a in ?? () (kgdb) Cheers, -- Mark A. R. Knight finger: markk@knigma.org Tel: +44 7880 556751 http://www.knigma.org/
In message <9paKSGHVcW++EwV8@lap.knigma.org>, Mark Knight <markk@knigma.org> writes>I just updated my system to RELENG_4 from Tuesday morning, and saw a >crash as X started. Unfortunately, It was a remote restart, so I had to >win a race to move xdm out of the way before the system crashed ;)Regressing my world and kernel back to: -rRELENG_4 -D "2003/06/06 13:20:00 PDT" appears to remove this problem. Moving forward to: -rRELENG_4 -D "2003/06/08 13:20:00 PDT" makes it return, providing a remarkably similar window to the apache panics thread. -- Mark A. R. Knight finger: markk@knigma.org Tel: +44 7880 556751 http://www.knigma.org/