Date: Tue, 16 Jan 2007 19:18:39 +0100 From: Divacky Roman <xdivac02@stud.fit.vutbr.cz> To: Scot Hetzel <swhetzel@gmail.com> Cc: emulation@freebsd.org, Alexander Leidinger <Alexander@leidinger.net> Subject: Re: linuxolator: fatal trap 12 when compiling libX11 Message-ID: <20070116181839.GA80994@stud.fit.vutbr.cz> In-Reply-To: <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 16, 2007 at 12:05:37PM -0600, Scot Hetzel wrote:
> On 1/16/07, Alexander Leidinger <Alexander@leidinger.net> wrote:
> >Please compile with debug symbols ("makeoptions DEBUG=-g" in the
> >kernel config), generate a coredump and run kgdb on it. If you load
> >modules, you need to run "make gdbinit" in the kernel compile
> >directory (old style kernel compiling, not the make buildkernel one).
> >This will allow to run "kldsyms" in kgdb which loads the debug symbols
> >for the modules. A trace will show the line numbers then.
> >
>
> # uname -a
> FreeBSD hp010 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Tue Jan 16 01:47:09
> CST 2007 swhetzel@hp010:/usr/src/7x/sys-orig/amd64/compile/GENERIC.debug
> amd64
>
> NOTE: GENERIC.debug is the same as the GENERIC config file, except I
> removed the debugging options from GENERIC, and placed them in
> GENERIC.debug. GENERIC.debug just includes GENERIC.
>
> # cd /usr/src/7x/sys-orig/amd64/compile/GENERIC.debug
> # kdb -n 0 kernel.debug
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x0
> fault code = supervisor read data, page not present
> instruction pointer = 0x8:0xffffffffa2cb3ce8
> stack pointer = 0x10:0xffffffffa314e9d0
> frame pointer = 0x10:0xffffffffa314ea50
> 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 = 23285 (bash)
> panic: from debugger
> cpuid = 0
> Uptime: 22m17s
> Physical memory: 1008 MB
> Dumping 122 MB: 107 91 75 59 43 27 11
>
> #0 doadump () at pcpu.h:172
> 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
> (kgdb) kldsysms
> :
> (kgdb) list *0xffffffffa2cb3ce8
> 0xffffffffa2cb3ce8 is in linux_proc_exit
> (/usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173).
> 168 child_clear_tid = em->child_clear_tid;
> 169
> 170 EMUL_UNLOCK(&emul_lock);
> 171
> 172 EMUL_SHARED_WLOCK(&emul_shared_lock);
> 173 LIST_REMOVE(em, threads);
> 174
> 175 PROC_LOCK(p);
> 176 p->p_emuldata = NULL;
> 177 PROC_UNLOCK(p);
> (kgdb) backtrace
> #0 doadump () at pcpu.h:172
> During symbol reading, Incomplete CFI data; unspecified registers at
> 0xffffffff80445bbc.
> #1 0xffffffff804464b9 in boot (howto=0x104) at
> ../../../kern/kern_shutdown.c:411
> #2 0xffffffff80445f47 in panic (fmt=0xffffffff806a82a7 "from
> debugger") at ../../../kern/kern_shutdown.c:567
> #3 0xffffffff801ac8c7 in db_panic (addr=0x0, have_addr=0x0,
> count=0x0, modif=0x0) at ../../../ddb/db_command.c:433
> #4 0xffffffff801acd69 in db_command_loop () at
> ../../../ddb/db_command.c:401
> #5 0xffffffff801aec73 in db_trap (type=0xa314e6d0, code=0x0) at
> ../../../ddb/db_main.c:222
> #6 0xffffffff8046c428 in kdb_trap (type=0xc, code=0x0,
> tf=0xffffffffa314e920) at ../../../kern/subr_kdb.c:502
> #7 0xffffffff80654f41 in trap_fatal (frame=0xffffffffa314e920,
> eva=0xffffff00279ee000)
> at ../../../amd64/amd64/trap.c:691
> #8 0xffffffff80655313 in trap_pfault (frame=0xffffffffa314e920,
> usermode=0x0) at ../../../amd64/amd64/trap.c:614
> #9 0xffffffff80655575 in trap (frame=0xffffffffa314e920) at
> ../../../amd64/amd64/trap.c:382
> #10 0xffffffff8063d39e in calltrap () at
> ../../../amd64/amd64/exception.S:169
> #11 0xffffffffa2cb3ce8 in linux_proc_exit (arg=0x4, p=0xffffff002670ba80)
> at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173
> #12 0xffffffff8042a689 in exit1 (td=0xffffff00279ee000, rv=0x0) at
> ../../../kern/kern_exit.c:233
> #13 0xffffffffa2cbe5a1 in linux_exit_group (td=0xffffff00279ee000,
> args=0xffffffffa314ebe0)
> at
> /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_misc.c:1634
> #14 0xffffffff8068e0a0 in ia32_syscall (frame=0xffffffffa314ec80) at
> ../../../amd64/ia32/ia32_syscall.c:187
> #15 0xffffffff8063d780 in Xint0x80_syscall () at ia32_exception.S:65
> #16 0x00000000281923e3 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb) frame 11
> #11 0xffffffffa2cb3ce8 in linux_proc_exit (arg=0x4, p=0xffffff002670ba80)
> at /usr/src/7x/sys-orig/modules/linux/../../compat/linux/linux_emul.c:173
> 173 LIST_REMOVE(em, threads);
> (kgdb) p *em
> $2 = {
> pid = 0x5af5,
> child_set_tid = 0x0,
> child_clear_tid = 0x0,
> shared = 0xffffff002ea8b8f0,
> pdeath_signal = 0x0,
> threads = {
> le_next = 0x0,
> le_prev = 0x0
> }
> }
I dont understand why it paniced. the threads LIST is empty
and LIST_REMOVE(something, empty_list) is perfectly legal.
can someone shed some light to this?
scot, can you please describe whats going on? I mean.. fbsd shell
forks-and-execs linux XYZ, XYZ execs ABC, something like that.
when you run with WITNESS/INVARIATNS does it spit any useful info?
thnx
roman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070116181839.GA80994>