Fatal trap 12 in exec_copyout_strings()
Andrew Gallatin
gallatin at cs.duke.edu
Tue Jun 21 20:00:28 GMT 2005
John Baldwin writes:
> On Sunday 29 May 2005 01:50 pm, Kris Kennaway wrote:
> > On Tue, May 10, 2005 at 03:36:36PM -0700, Kris Kennaway wrote:
> > > Got this on a dual amd64 with 8GB RAM running 6.0 from last week:
> > >
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 1; apic id = 01
> > > fault virtual address = 0xffffffffa9cdc000
> > > fault code = supervisor read, page not present
> > > instruction pointer = 0x8:0xffffffff8037759f
> > > stack pointer = 0x10:0xffffffffba1637d0
> > > frame pointer = 0x10:0xffffffffba163820
> > > code segment = base 0x0, limit 0xfffff, type 0x1b
> > > = DPL 0, pres 1, long 1, def32 0, gran 1
> > > processor eflags = interrupt enabled, resume, IOPL = 0
> > > current process = 52247 (sh)
> > > [thread pid 52247 tid 100149 ]
> > > Stopped at exec_copyout_strings+0x12f:
> > > db> wh
> > > Tracing pid 52247 tid 100149 td 0xffffff016e5724c0
> > > exec_copyout_strings() at exec_copyout_strings+0x12f
> > > do_execve() at do_execve+0x39a
> > > kern_execve() at kern_execve+0xab
> > > execve() at execve+0x49
> > > syscall() at syscall+0x382
> > > Xfast_syscall() at Xfast_syscall+0xa8
> > > --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090622c, rsp =
> > > 0x7fffffffe058, rbp = 0xffffffff --- db>
> >
> > I've got this panic twice more since.
>
> Do you have a kernel.debug? Can you do 'list *exec_copyout_strings+0x12f'? I
> think I've seen reports of the linux32_exec_copyout_strings() having a
> similar fault as well on amd64.
I just got this on my freshly installed UP, 512MB athlon64. For me,
its 100% reproducable when running a cross-compiler built on
FreeBSD-4.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xffffffff90ba3000
fault code = supervisor read, page not present
instruction pointer = 0x8:0xffffffff80412c20
stack pointer = 0x10:0xffffffff9666b730
frame pointer = 0x10:0xffffffff9666b770
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 2095 (lanai-gcc)
[thread pid 2095 tid 100077 ]
Stopped at ia32_copyout_strings+0x110:
Even after compiling with -O -pipe -g, GDB's stack trace is not so great:
#0 doadump () at pcpu.h:172
#1 0xffffffff801877a3 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0x0)
at ../../../ddb/db_command.c:531
#2 0xffffffff801874f0 in db_command (last_cmdp=0xffffffff805caee8, cmd_table=0x0,
aux_cmd_tablep=0xffffffff80475ab0, aux_cmd_tablep_end=0xffffffff80475ab8)
at ../../../ddb/db_command.c:349
#3 0xffffffff80187617 in db_command_loop () at ../../../ddb/db_command.c:455
#4 0xffffffff801897a5 in db_trap (type=-1771653920, code=0)
at ../../../ddb/db_main.c:221
#5 0xffffffff802a87fd in kdb_trap (type=12, code=0, tf=0xffffffff9666b680)
at ../../../kern/subr_kdb.c:471
#6 0xffffffff803df595 in trap_fatal (frame=0xffffffff9666b680,
eva=18446744071842705408) at ../../../amd64/amd64/trap.c:650
#7 0xffffffff803df232 in trap_pfault (frame=0xffffffff9666b680, usermode=0)
at ../../../amd64/amd64/trap.c:578
#8 0xffffffff803dee6a in trap (frame=
{tf_rdi = 4294956412, tf_rsi = 4294956816, tf_rdx = -1771651824, tf_rcx = -1771651824, tf_r8 = 64, tf_r9 = 0, tf_rax = 0, tf_rbx = -1866846208, tf_rbp = -1771653264, tf_r10 = -1099156726496, tf_r11 = 264314796, tf_r12 = 4294956816, tf_r13 = 4294956416, tf_r14 = 23, tf_r15 = 46, tf_trapno = 12, tf_addr = -1866846208, tf_flags = -2143426697, tf_err = 0, tf_rip = -2143212512, tf_cs = 8, tf_rflags = 66118, tf_rsp = -1771653312, tf_ss = 16}) at ../../../amd64/amd64/trap.c:357
#9 0xffffffff803cdb8b in calltrap () at ../../../amd64/amd64/exception.S:172
---Type <return> to continue, or q <return> to quit---
#10 0x00000000ffffd57c in ?? ()
#11 0x00000000ffffd710 in ?? ()
#12 0xffffffff9666bd10 in ?? ()
#13 0xffffffff9666bd10 in ?? ()
#14 0x0000000000000040 in ?? ()
#15 0x0000000000000000 in ?? ()
#16 0x0000000000000000 in ?? ()
#17 0xffffffff90ba3000 in ?? ()
#18 0xffffffff9666b770 in ?? ()
#19 0xffffff0015275d20 in ?? ()
#20 0x000000000fc11fac in ?? ()
#21 0x00000000ffffd710 in ?? ()
#22 0x00000000ffffd580 in ?? ()
#23 0x0000000000000017 in ?? ()
#24 0x000000000000002e in ?? ()
#25 0x000000000000000c in ?? ()
#26 0xffffffff90ba3000 in ?? ()
#27 0xffffffff803de777 in suword32 () at ../../../amd64/amd64/support.S:452
#28 0x0000000000000000 in ?? ()
#29 0xffffffff80412c20 in ia32_copyout_strings (imgp=0xffffffff90ba3000)
at ../../../compat/ia32/ia32_sysvec.c:245
#30 0xffffffff8026b9c2 in do_execve (td=0xffffff00186ca980, args=0x0, mac_p=0x0)
at ../../../kern/kern_exec.c:452
#31 0xffffffff8026b52e in kern_execve (td=0xffffff00186ca980,
args=0xffffffff9666bb10, mac_p=0x0) at ../../../kern/kern_exec.c:250
#32 0xffffffff80411859 in freebsd32_execve (td=0xffffff00186ca980, uap=0x0)
at ../../../compat/freebsd32/freebsd32_misc.c:321
#33 0xffffffff80411047 in ia32_syscall (frame=
{tf_rdi = 0, tf_rsi = 0, tf_rdx = 1, tf_rcx = 134563369, tf_r8 = 0, tf_r9 = 0, tf_rax = 59, tf_rbx = 672188772, tf_rbp = 4294955352, tf_r10 = 0, tf_r11 = 0, tf_r12 = 0, tf_r13 = 0, tf_r14 = 0, tf_r15 = 0, tf_trapno = 0, tf_addr = 0, tf_flags = 12, tf_err = 2, tf_rip = 671876628, tf_cs = 27, tf_rflags = 647, tf_rsp = 4294955308, tf_ss = 35}) at ../../../amd64/ia32/ia32_syscall.c:186
#34 0xffffffff803cddfd in Xint0x80_syscall () at ia32_exception.S:64
The line number gdb says the crash happened on does not correspond to
what ddb says.
(kgdb) frame 29
#29 0xffffffff80412c20 in ia32_copyout_strings (imgp=0xffffffff90ba3000)
at ../../../compat/ia32/ia32_sysvec.c:245
245 suword32(vectp++, (u_int32_t)(intptr_t)destp);
vs:
(kgdb) l *0xffffffff80412c20
0xffffffff80412c20 is in ia32_copyout_strings (../../../compat/ia32/ia32_sysvec.c:247).
242 * Fill in argument portion of vector table.
243 */
244 for (; argc > 0; --argc) {
245 suword32(vectp++, (u_int32_t)(intptr_t)destp);
246 while (*stringp++ != 0)
247 destp++;
248 destp++;
249 }
250
251 /* a null vector table pointer separates the argp's from the envp's */
The deref of stringp makes sense, as it corresponds to the faulting
address reported in ddb:
(kgdb) p stringp
$27 = 0xffffffff90ba3000 <Address 0xffffffff90ba3000 out of bounds>
(kgdb) p *imgp->args
$33 = {
buf = 0xffffffff90ba3000 <Address 0xffffffff90ba3000 out of bounds>,
begin_argv = 0xffffffff90ba3000 <Address 0xffffffff90ba3000 out of bounds>,
begin_envv = 0xffffffff90ba313d <Address 0xffffffff90ba313d out of bounds>,
endp = 0xffffffff90ba389f <Address 0xffffffff90ba389f out of bounds>,
fname = 0xffffffff90be3000 "/home/gallatin/lanaitools/intel_FreeBSD/lib/gcc-lib/lanai/2.95.2..1.6/cc1",
stringspace = 259937,
argc = 23,
envc = 46
}
I'm puzzled. fname seems to be buf+ARGV_MAX, so its not
like something randomly scribbled on this memory.
In the debugger, the memory just below buf+ARGV_MAX seems to be
unmapped. But we've done copyins in freebsd32_exec_copyin_args(),
otherwise endp would not have been advanced. So we've written to this
memory.
It is almost like somebody freed buf through buf + 262144.
Drew
More information about the freebsd-amd64
mailing list