Re: [ge...@dts.su: Re[2]: fatal trap 12]
[Please, remove the questions@ on the reply, this is the topic for
f...@].
On Sat, Jun 06, 2009 at 08:16:00PM +0400, Chagin Dmitry wrote:
- Forwarded message from ge...@dts.su -
Date: Sat, 6 Jun 2009 10:58:11 +0400
From: ge...@dts.su
To: freebsd-questions@freebsd.org
Subject: Re[2]: fatal trap 12
Hello, Freebsd-questions.
After one of new crash I have this:
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 amd64-marcel-freebsd...
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0x0
fault code = supervisor read data, page not present
instruction pointer = 0x8:0x804c4eb8
stack pointer = 0x10:0xff807a0478f0
frame pointer = 0x10:0xff807a047930
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 32668 (perl5.10.0)
Physical memory: 4082 MB
Dumping 1647 MB: 1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456
1440 1424 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216
1200 1184 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960
944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656
640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352
336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16
Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from
/boot/kernel/accf_http.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/accf_http.ko
#0 doadump () at pcpu.h:195
195 __asm __volatile(movq %%gs:0,%0 : =r (td));
(kgdb) list *0x804c4eb8
0x804c4eb8 is in pfs_ioctl
(/usr/src/sys/fs/pseudofs/pseudofs_vnops.c:265).
260 static int
261 pfs_ioctl(struct vop_ioctl_args *va)
262 {
263 struct vnode *vn = va-a_vp;
264 struct pfs_vdata *pvd = vn-v_data;
265 struct pfs_node *pn = pvd-pvd_pn;
266 struct proc *proc;
267 int error;
268
269 PFS_TRACE((%s: %lx, pn-pn_name, va-a_command));
(kgdb) backtrace
#0 doadump () at pcpu.h:195
#1 0x801c8dac in db_fncall (dummy1=Variable dummy1 is not
available.
) at /usr/src/sys/ddb/db_command.c:516
#2 0x801c92df in db_command (last_cmdp=0x80b30c88,
cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:413
#3 0x801c94f0 in db_command_loop () at
/usr/src/sys/ddb/db_command.c:466
#4 0x801cb0d9 in db_trap (type=Variable type is not available.
) at /usr/src/sys/ddb/db_main.c:228
#5 0x80554e55 in kdb_trap (type=12, code=0, tf=0xff807a047840)
at /usr/src/sys/kern/subr_kdb.c:524
#6 0x807fae80 in trap_fatal (frame=0xff807a047840, eva=Variable
eva is not available.
) at /usr/src/sys/amd64/amd64/trap.c:752
#7 0x807fb254 in trap_pfault (frame=0xff807a047840, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:673
#8 0x807fbc02 in trap (frame=0xff807a047840) at
/usr/src/sys/amd64/amd64/trap.c:444
#9 0x807df35e in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:209
#10 0x804c4eb8 in pfs_ioctl (va=0xff807a047a10) at
/usr/src/sys/fs/pseudofs/pseudofs_vnops.c:264
#11 0x805bb1d3 in vn_ioctl (fp=Variable fp is not available.
) at vnode_if.h:437
#12 0x80562d02 in kern_ioctl (td=0xff0006682000, fd=3,
com=1076655123, data=0xff00ad2b7d40 ) at file.h:269
#13 0x80563029 in ioctl (td=0xff0006682000,
uap=0xff807a047bf0) at /usr/src/sys/kern/sys_generic.c:571
#14 0x807fb4d6 in syscall (frame=0xff807a047c80) at
/usr/src/sys/amd64/amd64/trap.c:900
#15 0x807df56b in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:330
#16 0x000800c9c0ec in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Can You help me? What can I do? Server crash periodicaly...
The issue is that VOP_IOCTL interface takes unlocked vnode, which
may be reclaimed at any moment. The right thing to do is to fix
this before 8.0 freezed KPI. Please, try the patch below.
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
index a7f47b2..018e6bd 100644
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
@@ -258,7 +258,7 @@
Re: sleeping without queue ?
On Tue, Jul 22, 2008 at 01:09:28PM -0400, Mikhail Teterin wrote: Kris Kennaway написав(ла): Mikhail Teterin wrote: Kris Kennaway написав(ла): Well, I mean kernel backtrace. Can I obtain that remotely and without restarting/panicking the box? Thanks, kgdb on /dev/mem or procstat [EMAIL PROTECTED]:~ (107) kgdb /boot/kernel/kernel /dev/mem [...] (kgdb) bt #0 0x in ?? () Error accessing memory address 0x0: Bad address. Even less luck with procstat: [EMAIL PROTECTED]:~ (108) locate procstat [EMAIL PROTECTED]:~ (109) procstat procstat: Нев?дома команда. [EMAIL PROTECTED]:~ (110) man procstat No manual entry for procstat I'm sorry, but you'll need to be more specific. What should I type? Thanks, Did you switched to the process before doing backtrace (using the proc pid command) ? What is the exact version of the system ? Note that procstat appeared in the late RELENG_7. Also, show the output of ps axl pid. pgps6aEl30pRA.pgp Description: PGP signature
Re: how sys_select, sys_fork, ... are defined for thread libraries?
On Thu, Aug 02, 2007 at 02:00:05PM -0700, Jin Guojun wrote: I am trying to understand how these __sys_xxx functions are defined for thread libraries. Following string search tells that all thread libraries are using these __sys_xxx functions, for example, __sys_select(). However, the search also shows that these functions are not defined anywhere in the entire source tree. /usr/src: findstring sys_select *.[hcS] total files= 21687 : pattern= sys_select rootdir= /usr/src regular mode: Thu Aug 2 13:31:40 PDT 2007 ./lib/libc_r/uthread/uthread_fork.c 91: * __sys_select: ./lib/libpthread/thread/thr_private.h 1264:int __sys_select(int, fd_set *, fd_set *, fd_set *, struct timeval *); ./lib/libpthread/thread/thr_select.c 61: ret = __sys_select(numfds, readfds, writefds, exceptfds, timeout); ./lib/libthr/thread/thr_private.h 805:int __sys_select(int, fd_set *, fd_set *, fd_set *, struct timeval *); ./lib/libthr/thread/thr_syscalls.c 435:ret = __sys_select(numfds, readfds, writefds, exceptfds, timeout); By searching the usr/lib objects, I found them in libc, but they are not in libc source tree. Can someone shed some light on how these system calls are built into libc and what is the different between standard syscall APIs and these __sys_syscall APIs, e.g., __sys_read() vs. read(), etc. Thanks, -Jin nm /usr/lib/libc.a | grep __sys_ 0008 T __sys_sigreturn 0008 T __sys_setlogin 0008 T __sys_reboot ... snapped 0008 T __sys_kse_release 0008 T __sys_kse_thr_interrupt 0008 T __sys_kse_create 0008 T __sys_kse_wakeup ... skipped 0008 T __sys_getdtablesize 0008 T __sys_select 0008 T __sys_ioctl 0008 T __sys_close 0008 T __sys_write 0008 T __sys_read 0008 T __sys___syscall The C standard specifies that namespace of identifiers starting with __ or _UPPERCASE is reserved for implementation. On the other hand, C standard allows for the programs to use any symbol not reserved by standard. The thread libraries (and libc) shall internally use the right implementation of syscalls, as opposed to some symbol supplied by user binary. To achieve this, for each syscall x, libc defines the normal symbol __sys_x, and two weak symbols _x and x. See, for instance, the file lib/libc/select.S from the obj directory, and lib/libc/i386/SYS.h for corresponding include file. Definition of weak symbols is provided by ELF specification. Simplyfing, weakness of the symbol mean that it is used only unless somebody provides the same normal symbol. Normal symbols from text segment are marked by T in nm output, and weak symbols has t mark. pgp6Dcyp1BXUr.pgp Description: PGP signature
