Date: Sat, 23 Apr 2005 01:05:02 -0700 From: Kris Kennaway <kris@obsecurity.org> To: sparc64@FreeBSD.org Subject: panic upon deleting DDB breakpoint Message-ID: <20050423080502.GA97360@xor.obsecurity.org>
next in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
I did the following on a RELENG_5 machine (in the course of trying to
track down my errno problem previously reported):
db> break unlink
db> cont
[thread pid 57866 tid 100044 ]
Breakpoint at unlink: save %sp, -0xc0, %sp
db> delete unlink
db> cont
panic: trap: fast data access mmu miss
cpuid = 0
KDB: enter: panic
[thread pid 57866 tid 100044 ]
Stopped at kdb_enter+0x38: ta %xcc, 1
db> wh
Tracing pid 57866 tid 100044 td 0xfffff8003f817400
panic() at panic+0x19c
trap() at trap+0x16c
-- fast data access mmu miss tar=0 %o7=0xc01ab278 --
unlink() at unlink+0x20
-- syscall (10, FreeBSD ELF64, unlink) %o7=0x10352c --
userland() at 0x403a4e68
user trace: trap %o7=0x10352c
pc 0x403a4e68, sp 0x7fdffffd5e1
pc 0x1040d8, sp 0x7fdffffdb21
pc 0x1013b4, sp 0x7fdffffdbe1
pc 0x40217414, sp 0x7fdffffdca1
done
This is repeatable on two machines; I have a coredump.
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:246
#1 0x00000000c01698b4 in boot (howto=260) at ../../../kern/kern_shutdown.c:409
#2 0x00000000c0169cc4 in panic (fmt=0xc03ae988 "trap: %s") at ../../../kern/kern_shutdown.c:565
#3 0x00000000c02e978c in trap (tf=0xee9175c0) at ../../../sparc64/sparc64/trap.c:369
#4 0x00000000c01d30c4 in unlink (td=0xee917880, uap=0x0) at ../../../kern/vfs_syscalls.c:1585
#5 0x00000000c01d30b8 in unlink (td=0xee917880, uap=0x0) at ../../../kern/vfs_syscalls.c:1584
(kgdb) frame 3
#3 0x00000000c02e978c in trap (tf=0xee9175c0) at ../../../sparc64/sparc64/trap.c:369
369 panic("trap: %s", trap_msg[tf->tf_type & ~T_KERNEL]);
(kgdb) frame 4
#4 0x00000000c01d30c4 in unlink (td=0xee917880, uap=0x0) at ../../../kern/vfs_syscalls.c:1585
1585 error = kern_unlink(td, uap->path, UIO_USERSPACE);
(kgdb) frame 5
#5 0x00000000c01d30b8 in unlink (td=0xee917880, uap=0x0) at ../../../kern/vfs_syscalls.c:1584
1584 mtx_lock(&Giant);
(kgdb)
(Take the above with a grain of salt since gdb53 got the stack trace
wrong).
I didn't yet try other breakpoints. Doing the same thing on i386
doesn't cause a panic.
Kris
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFCagGuWry0BWjoQKURAol1AKCB+d1MsD+vWA1ZvwG0axHUQohFxgCfYkes
k0GvZT11rocvXRrOcxoithg=
=8gic
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050423080502.GA97360>