Bug 176835

Summary:	Fatal trap 12: page fault while in kernel mode
Product:	Base System	Reporter:	Martin Bishop <martin.bishop>
Component:	amd64	Assignee:	Mark Linimon <linimon>
Status:	Closed Overcome By Events
Severity:	Affects Only Me
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description Martin Bishop 2013-03-11 06:50:00 UTC

Periodic panic, though it looks like it's happening in the same place. Stealing some advice from another bug report, there's some gdb output at the bottom..

panic #1
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0xffffffffd398481f
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff808eb0b3
stack pointer           = 0x28:0xffffff80913d4970
frame pointer           = 0x28:0xffffff80913d4980
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 91049 (maildrop)
trap number             = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0xffffffff809208a6 at kdb_backtrace+0x66
#1 0xffffffff808ea8be at panic+0x1ce
#2 0xffffffff80bd8240 at trap_fatal+0x290
#3 0xffffffff80bd857d at trap_pfault+0x1ed
#4 0xffffffff80bd8b9e at trap+0x3ce
#5 0xffffffff80bc315f at calltrap+0x8
#6 0xffffffff808efb14 at tdsendsignal+0x454
#7 0xffffffff808f0b6d at killpg1+0x3bd
#8 0xffffffff808f0de4 at sys_kill+0x1e4
#9 0xffffffff80bd7ae6 at amd64_syscall+0x546

panic #2

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0xffffffffd398481f
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff808eb0b3
stack pointer           = 0x28:0xffffff8091109970
frame pointer           = 0x28:0xffffff8091109980
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 57769 (maildrop)
trap number             = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0xffffffff809208a6 at kdb_backtrace+0x66
#1 0xffffffff808ea8be at panic+0x1ce
#2 0xffffffff80bd8240 at trap_fatal+0x290
#3 0xffffffff80bd857d at trap_pfault+0x1ed
#4 0xffffffff80bd8b9e at trap+0x3ce
#5 0xffffffff80bc315f at calltrap+0x8
#6 0xffffffff808efb14 at tdsendsignal+0x454
#7 0xffffffff808f0b6d at killpg1+0x3bd
#8 0xffffffff808f0de4 at sys_kill+0x1e4
#9 0xffffffff80bd7ae6 at amd64_syscall+0x546

% gdb /boot/kernel/kernel
<snip>
(gdb) l *tdsendsignal+0x454
0xffffffff808efb14 is in tdsendsignal (/usr/src/sys/kern/kern_sig.c:2046).
warning: Source file is more recent than executable.

2041             * IEEE Std 1003.1-2001: return success when killing a zombie.
2042             */
2043            if (p->p_state == PRS_ZOMBIE) {
2044                    if (ksi && (ksi->ksi_flags & KSI_INS))
2045                            ksiginfo_tryfree(ksi);
2046                    return (ret);
2047            }
2048
2049            ps = p->p_sigacts;
2050            KNOTE_LOCKED(&p->p_klist, NOTE_SIGNAL | sig);
(gdb) 

I can grab a core if need be, but am hoping that given the consistency of the backtrace the problem will be obvious to the maintainers of the relevant portions of code :)

How-To-Repeat: I haven't been triggering it, but given the current process is consistently the same:

- run 9.1 release
- use maildrop to filter mail
- wait for crash

Comment 1 Kostik Belousov 2013-03-11 12:01:52 UTC

On Mon, Mar 11, 2013 at 06:40:52AM +0000, Martin Bishop wrote:
> I can grab a core if need be, but am hoping that given the consistency of the backtrace the problem will be obvious to the maintainers of the relevant portions of code :)

You do need to grab core, and use the sources corresponding to your kernel.
The data you demonstrated do not tell much.

If the faulting address was an attempt to access any non-trivial structure,
then it is very suspicious, both because the faulting addresses are same
for both panics, and because the address is not aligned.

Comment 2 Martin Bishop 2013-03-18 05:33:50 UTC

After one more crash to enable dumping, and one to produce a core.

Backtrace from kgdb

(kgdb) bt
#0  doadump (textdump=Variable "textdump" is not available.
) at pcpu.h:224
#1  0xffffffff808ea3a1 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:448
#2  0xffffffff808ea897 in panic (fmt=0x1 <Address 0x1 out of bounds>)
at /usr/src/sys/kern/kern_shutdown.c:636
#3  0xffffffff80bd8240 in trap_fatal (frame=0xc, eva=Variable "eva" is
not available.
) at /usr/src/sys/amd64/amd64/trap.c:857
#4  0xffffffff80bd857d in trap_pfault (frame=0xffffff80913118c0,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:773
#5  0xffffffff80bd8b9e in trap (frame=0xffffff80913118c0) at
/usr/src/sys/amd64/amd64/trap.c:456
#6  0xffffffff80bc315f in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:228
#7  0xffffffff808eb0b3 in sigtd (p=0xfffffe00212d3000, sig=1,
prop=Variable "prop" is not available.
) at /usr/src/sys/kern/kern_sig.c:1927
#8  0xffffffff808efb14 in tdsendsignal (p=0xfffffe00212d3000, td=0x0,
sig=1, ksi=0xffffff8091311a70) at /usr/src/sys/kern/kern_sig.c:2045
#9  0xffffffff808f0b6d in killpg1 (td=0xfffffe00341278e0, sig=1,
pgid=Variable "pgid" is not available.
) at /usr/src/sys/kern/kern_sig.c:1650
#10 0xffffffff808f0de4 in sys_kill (td=0xfffffe00341278e0,
uap=0xffffff8091311bb0) at /usr/src/sys/kern/kern_sig.c:1703
#11 0xffffffff80bd7ae6 in amd64_syscall (td=0xfffffe00341278e0,
traced=0) at subr_syscall.c:135
#12 0xffffffff80bc3447 in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:387
#13 0x00000008015dbc2c in ?? ()

Any particular information to grab to make this easier to track down ?

Comment 3 Eitan Adler freebsd_committer

2017-12-31 07:59:13 UTC

For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped

Comment 4 Mark Linimon freebsd_committer

2018-05-31 15:47:17 UTC

Unfortunately this PR was never addressed before these versions of FreeBSD went out of support.  Sorry.

If this is still a problem, please open a new PR.  Thanks.