From owner-freebsd-emulation@FreeBSD.ORG Tue Jan 16 18:37:01 2007 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A3FF16A416 for ; Tue, 16 Jan 2007 18:37:01 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.176.14]) by mx1.freebsd.org (Postfix) with ESMTP id E3E4113C45E for ; Tue, 16 Jan 2007 18:37:00 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.8/8.13.7) with ESMTP id l0GIIeBP081920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Jan 2007 19:18:40 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.8/8.13.3/Submit) id l0GIIeFP081919; Tue, 16 Jan 2007 19:18:40 +0100 (CET) Date: Tue, 16 Jan 2007 19:18:39 +0100 From: Divacky Roman To: Scot Hetzel Message-ID: <20070116181839.GA80994@stud.fit.vutbr.cz> References: <790a9fff0701151314x6dd48ecbg90a54729813e84e@mail.gmail.com> <20070116080015.8dus0vamssso0sww@webmail.leidinger.net> <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <790a9fff0701161005t75222f2l439e8c0c1153ffd2@mail.gmail.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.57 on 147.229.176.14 Cc: emulation@freebsd.org, Alexander Leidinger Subject: Re: linuxolator: fatal trap 12 when compiling libX11 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 18:37:01 -0000 On Tue, Jan 16, 2007 at 12:05:37PM -0600, Scot Hetzel wrote: > On 1/16/07, Alexander Leidinger 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