From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 27 11:07:27 2012 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 733C81065691 for ; Mon, 27 Feb 2012 11:07:27 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 47DFB8FC15 for ; Mon, 27 Feb 2012 11:07:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1RB7RtA090165 for ; Mon, 27 Feb 2012 11:07:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1RB7Qcq090161 for freebsd-emulation@FreeBSD.org; Mon, 27 Feb 2012 11:07:26 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Feb 2012 11:07:26 GMT Message-Id: <201202271107.q1RB7Qcq090161@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-emulation@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org 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: Mon, 27 Feb 2012 11:07:27 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/159646 emulation [linux] [patch] bump Linux version in linuxulator f kern/156691 emulation [vmware] [panic] panic when using hard disks as RAW de o kern/156353 emulation [ibcs2] ibcs2 binaries that execute on 4.x not working o kern/155577 emulation [boot] BTX halted after install. Reboot during install o kern/155040 emulation [linux] [patch] Linux recvfrom doesn't handle proto fa o kern/153990 emulation [hyper-v]: Will not install into Hyper-V on Server 200 o kern/153887 emulation [linux] Linux emulator not understand STB_GNU_UNIQUE b o kern/153243 emulation [ibcs2] Seg fault whne running COFF binary using iBCS2 o kern/151714 emulation [linux] print/acroread9 not usable due to lack of supp a bin/150262 emulation [patch] truss(1) -f doesn't follow descendants of the a kern/150186 emulation [parallels] [panic] Parallels Desktop: CDROM disconnec o ports/148097 emulation [patch] suggested addition to linux_base-* packages to o ports/148096 emulation emulators/linux_base-* can not be built from ports on o kern/147793 emulation [vmware] [panic] cdrom handling, panic, possible race o kern/146237 emulation [linux] Linux binaries not reading directories mounted p kern/144584 emulation [linprocfs][patch] bogus values in linprocfs o ports/142837 emulation [patch] emulators/linux_base-* packages fails to insta o kern/140156 emulation [linux] cdparanoia fails to read drive data f kern/138944 emulation [parallels] [regression] Parallels no longer works in o kern/138880 emulation [linux] munmap segfaults after linux_mmap2 stresstest o ports/135337 emulation [PATCH] emulators/linux_base-f10: incorrect bash usage s kern/133144 emulation [linux] linuxulator 2.6 crashes with nvidias libGL.so. o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o kern/86619 emulation [linux] linux emulator interacts oddly with cp a kern/72920 emulation [linux] path "prefixing" is not done on unix domain so o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/36952 emulation [patch] [linux] ldd(1) command of linux does not work o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 30 problems total. From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 27 12:49:27 2012 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B11E1065705 for ; Mon, 27 Feb 2012 12:49:27 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id CB5AC8FC17 for ; Mon, 27 Feb 2012 12:49:26 +0000 (UTC) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.4/8.14.4) with ESMTP id q1RCnOmC072370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Feb 2012 13:49:24 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.5/8.14.4) with ESMTP id q1RCnT10003175; Mon, 27 Feb 2012 13:49:29 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.5/8.14.5/Submit) id q1RCnSYC003174; Mon, 27 Feb 2012 13:49:28 +0100 (CET) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: Konstantin Belousov In-Reply-To: <20120225011228.GB55074@deviant.kiev.zoral.com.ua> (Konstantin Belousov's message of "Sat, 25 Feb 2012 03:12:28 +0200") References: <20120224142940.GR55074@deviant.kiev.zoral.com.ua> <20120225011228.GB55074@deviant.kiev.zoral.com.ua> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) Date: Mon, 27 Feb 2012 13:49:28 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emulation@freebsd.org Subject: Re: [Bengt Ahlgren] 8.3-PRERELEASE panic in linux emulation 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: Mon, 27 Feb 2012 12:49:27 -0000 Konstantin Belousov writes: > On Fri, Feb 24, 2012 at 09:55:31PM +0100, Bengt Ahlgren wrote: >> Bengt Ahlgren writes: >> >> > Konstantin Belousov writes: >> > >> >> On Fri, Feb 24, 2012 at 01:27:24PM +0100, Bengt Ahlgren wrote: >> >>> Hello! >> >>> >> >>> Perhaps emulation@ is a better place to report this problem? >> >>> >> >>> Bengt >> >>> >> >> >> >>> From: Bengt Ahlgren >> >>> To: stable@freebsd.org >> >>> Subject: 8.3-PRERELEASE panic in linux emulation >> >>> Date: Thu, 23 Feb 2012 17:26:32 +0100 >> >>> >> >>> Hi! >> >>> >> >>> I get a consistent panic when starting acroread after updating to >> >>> 8.3-PRERELEASE. An 8.2-STABLE from Feb 4th was OK. Can provide more >> >>> info if needed. >> >>> >> >>> Bengt >> >>> >> >>> FreeBSD xx.yy.zz 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #13 r231999: Wed Feb 22 21:01:38 CET 2012 bengta@P142.sics.se:/usr/obj/usr/src/sys/P142-82 i386 >> >>> >> >>> Fatal trap 12: page fault while in kernel mode >> >>> fault virtual address = 0xbfbfdffc >> >>> fault code = supervisor write, page not present >> >>> instruction pointer = 0x20:0xc50b396c >> >>> stack pointer = 0x28:0xe7481a6c >> >>> frame pointer = 0x28:0xe7481a90 >> >>> code segment = base 0x0, limit 0xfffff, type 0x1b >> >>> = DPL 0, pres 1, def32 1, gran 1 >> >>> processor eflags = interrupt enabled, resume, IOPL = 0 >> >>> current process = 1997 (bash) >> >>> trap number = 12 >> >>> panic: page fault >> >>> KDB: stack backtrace: >> >>> db_trace_self_wrapper(c091af2a,70797420,78302065,a0d6231,c5d6b600,...) at db_trace_self_wrapper+0x26 >> >>> kdb_backtrace(c0919061,c09b49a0,c0900251,e7481910,e7481910,...) at kdb_backtrace+0x2a >> >>> panic(c0900251,c0941cab,c5c246e8,1,1,...) at panic+0xaf >> >>> trap_fatal(c0670d02,0,e7481964,80400,c5c24580,...) at trap_fatal+0x353 >> >>> trap_pfault(e74819cc,bfbfe190,c5c24580,202,c5cecac0,...) at trap_pfault+0x87 >> >>> trap(e7481a2c) at trap+0x453 >> >>> calltrap() at calltrap+0x6 >> >>> --- trap 0xc, eip = 0xc50b396c, esp = 0xe7481a6c, ebp = 0xe7481a90 --- >> >>> elf_linux_fixup(e7481c0c,e7481b98,c065ca92,c60ffce8,100000,...) at elf_linux_fixup+0x33c >> >>> kern_execve(c5c24580,e7481c3c,0,8112710,8116cd8,...) at kern_execve+0x7d6 >> >>> linux_execve(c5c24580,e7481cec,c,c,c,...) at linux_execve+0xa7 >> >>> syscall(e7481d28) at syscall+0x372 >> >>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >> >>> --- syscall (11, Linux ELF, linux_execve), eip = 0x281e0d4a, esp = 0xbfbfd644, ebp = 0xbfbfd7e8 --- >> >>> >> >>> #0 doadump () at pcpu.h:244 >> >>> #1 0xc05de609 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:441 >> >>> #2 0xc05de84f in panic (fmt=Variable "fmt" is not available. >> >>> ) at /usr/src/sys/kern/kern_shutdown.c:614 >> >>> #3 0xc08b22c3 in trap_fatal (frame=0xe7481a2c, eva=3217022972) at /usr/src/sys/i386/i386/trap.c:981 >> >>> #4 0xc08b2357 in trap_pfault (frame=0xe7481a2c, usermode=0, eva=3217022972) at /usr/src/sys/i386/i386/trap.c:843 >> >>> #5 0xc08b3133 in trap (frame=0xe7481a2c) at /usr/src/sys/i386/i386/trap.c:562 >> >>> #6 0xc089bedc in calltrap () at /usr/src/sys/i386/i386/exception.s:168 >> >>> #7 0xc50b396c in elf_linux_fixup (stack_base=0xe7481c0c, imgp=0xe7481b98) at /usr/src/sys/modules/linux/../../i386/linux/linux_sysvec.c:288 >> >>> #8 0xc05ac636 in kern_execve (td=0xc5c24580, args=0xe7481c3c, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:551 >> >>> #9 0xc50ab387 in linux_execve (td=0xc5c24580, args=0xe7481cec) at /usr/src/sys/modules/linux/../../i386/linux/linux_machdep.c:143 >> >>> #10 0xc08b2902 in syscall (frame=0xe7481d28) at subr_syscall.c:114 >> >>> #11 0xc089bf41 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 >> >>> #12 0x00000033 in ?? () >> >>> >> >> I am not sure if this is the real cause of your panic, but the line from >> >> the backtrace indeed has a bug. Please try the change below. >> >> >> >> diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linux_sysvec.c >> >> index 7634138..d4e23e1 100644 >> >> --- a/sys/i386/linux/linux_sysvec.c >> >> +++ b/sys/i386/linux/linux_sysvec.c >> >> @@ -227,11 +227,11 @@ linux_fixup(register_t **stack_base, struct image_params *imgp) >> >> argv = *stack_base; >> >> envp = *stack_base + (imgp->args->argc + 1); >> >> (*stack_base)--; >> >> - **stack_base = (intptr_t)(void *)envp; >> >> + suword(*stack_base, (intptr_t)(void *)envp); >> >> (*stack_base)--; >> >> - **stack_base = (intptr_t)(void *)argv; >> >> + suword(*stack_base, (intptr_t)(void *)argv); >> >> (*stack_base)--; >> >> - **stack_base = imgp->args->argc; >> >> + suword(*stack_base, imgp->args->argc); >> >> return (0); >> >> } >> >> >> >> @@ -286,7 +286,7 @@ elf_linux_fixup(register_t **stack_base, struct image_params *imgp) >> >> imgp->auxargs = NULL; >> >> >> >> (*stack_base)--; >> >> - **stack_base = (register_t)imgp->args->argc; >> >> + suword(*stack_base, (register_t)imgp->args->argc); >> >> return (0); >> >> } >> >> >> > >> > Thanks for the response! I will try the patch, but that file has not >> > been touched since June 2011. I was suspecting the changes in r231146 >> > and r231148. If there is no change with your patch I will roll back >> > those to see what happens. > This is very unlikely. fadvise() has nothing to do with image activators. > >> >> No panics so far. That patch does indeed seem to solve the problem! I >> also verified with going back to the old kernel, which again >> consistently paniced. > I will commit the change in minutes. Kernel must not access usermode > addresses directly. > > But, does the application that used to panic the system, behave properly ? Yes, it (acroread8) does behave properly with the patch. Have not tested extensively, however. >> Thanks very much for good work! >> >> I'm a but puzzled though, because that bug must have been there for >> quite some time without triggering the panic. > The panic with unpatched kernel looks puzzling. Do you have some > non-default stack limit ? Can you look at the resource limit values > for the process initiated the panic ? Not that I'm aware of. Unless the acroread launch script does this. I don't know how to check this for a running process, but "limits|grep stack" in a regular shell gives me: stacksize 65536 kB Or, do you mean that I can dig that out of the crash dump? If so, I'll need some help with how to. Bengt From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 27 14:31:52 2012 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C220106564A for ; Mon, 27 Feb 2012 14:31:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D1AD98FC17 for ; Mon, 27 Feb 2012 14:31:51 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1REViFd085705; Mon, 27 Feb 2012 16:31:44 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1REVhpA008965; Mon, 27 Feb 2012 16:31:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1REVhxW008964; Mon, 27 Feb 2012 16:31:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 Feb 2012 16:31:43 +0200 From: Konstantin Belousov To: Bengt Ahlgren Message-ID: <20120227143143.GE55074@deviant.kiev.zoral.com.ua> References: <20120224142940.GR55074@deviant.kiev.zoral.com.ua> <20120225011228.GB55074@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D90rafnCA5jqK2oI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: emulation@freebsd.org Subject: Re: [Bengt Ahlgren] 8.3-PRERELEASE panic in linux emulation 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: Mon, 27 Feb 2012 14:31:52 -0000 --D90rafnCA5jqK2oI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 27, 2012 at 01:49:28PM +0100, Bengt Ahlgren wrote: > Konstantin Belousov writes: >=20 > > On Fri, Feb 24, 2012 at 09:55:31PM +0100, Bengt Ahlgren wrote: > >> Bengt Ahlgren writes: > >>=20 > >> > Konstantin Belousov writes: > >> > > >> >> On Fri, Feb 24, 2012 at 01:27:24PM +0100, Bengt Ahlgren wrote: > >> >>> Hello! > >> >>>=20 > >> >>> Perhaps emulation@ is a better place to report this problem? > >> >>>=20 > >> >>> Bengt > >> >>>=20 > >> >> > >> >>> From: Bengt Ahlgren > >> >>> To: stable@freebsd.org > >> >>> Subject: 8.3-PRERELEASE panic in linux emulation > >> >>> Date: Thu, 23 Feb 2012 17:26:32 +0100 > >> >>>=20 > >> >>> Hi! > >> >>>=20 > >> >>> I get a consistent panic when starting acroread after updating to > >> >>> 8.3-PRERELEASE. An 8.2-STABLE from Feb 4th was OK. Can provide m= ore > >> >>> info if needed. > >> >>>=20 > >> >>> Bengt > >> >>>=20 > >> >>> FreeBSD xx.yy.zz 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #13 r231999= : Wed Feb 22 21:01:38 CET 2012 bengta@P142.sics.se:/usr/obj/usr/src/sys= /P142-82 i386 > >> >>>=20 > >> >>> Fatal trap 12: page fault while in kernel mode > >> >>> fault virtual address =3D 0xbfbfdffc > >> >>> fault code =3D supervisor write, page not present > >> >>> instruction pointer =3D 0x20:0xc50b396c > >> >>> stack pointer =3D 0x28:0xe7481a6c > >> >>> frame pointer =3D 0x28:0xe7481a90 > >> >>> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >> >>> =3D DPL 0, pres 1, def32 1, gran 1 > >> >>> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >> >>> current process =3D 1997 (bash) > >> >>> trap number =3D 12 > >> >>> panic: page fault > >> >>> KDB: stack backtrace: > >> >>> db_trace_self_wrapper(c091af2a,70797420,78302065,a0d6231,c5d6b600,= ...) at db_trace_self_wrapper+0x26 > >> >>> kdb_backtrace(c0919061,c09b49a0,c0900251,e7481910,e7481910,...) at= kdb_backtrace+0x2a > >> >>> panic(c0900251,c0941cab,c5c246e8,1,1,...) at panic+0xaf > >> >>> trap_fatal(c0670d02,0,e7481964,80400,c5c24580,...) at trap_fatal+0= x353 > >> >>> trap_pfault(e74819cc,bfbfe190,c5c24580,202,c5cecac0,...) at trap_p= fault+0x87 > >> >>> trap(e7481a2c) at trap+0x453 > >> >>> calltrap() at calltrap+0x6 > >> >>> --- trap 0xc, eip =3D 0xc50b396c, esp =3D 0xe7481a6c, ebp =3D 0xe7= 481a90 --- > >> >>> elf_linux_fixup(e7481c0c,e7481b98,c065ca92,c60ffce8,100000,...) at= elf_linux_fixup+0x33c > >> >>> kern_execve(c5c24580,e7481c3c,0,8112710,8116cd8,...) at kern_execv= e+0x7d6 > >> >>> linux_execve(c5c24580,e7481cec,c,c,c,...) at linux_execve+0xa7 > >> >>> syscall(e7481d28) at syscall+0x372 > >> >>> Xint0x80_syscall() at Xint0x80_syscall+0x21 > >> >>> --- syscall (11, Linux ELF, linux_execve), eip =3D 0x281e0d4a, esp= =3D 0xbfbfd644, ebp =3D 0xbfbfd7e8 --- > >> >>>=20 > >> >>> #0 doadump () at pcpu.h:244 > >> >>> #1 0xc05de609 in boot (howto=3D260) at /usr/src/sys/kern/kern_shu= tdown.c:441 > >> >>> #2 0xc05de84f in panic (fmt=3DVariable "fmt" is not available. > >> >>> ) at /usr/src/sys/kern/kern_shutdown.c:614 > >> >>> #3 0xc08b22c3 in trap_fatal (frame=3D0xe7481a2c, eva=3D3217022972= ) at /usr/src/sys/i386/i386/trap.c:981 > >> >>> #4 0xc08b2357 in trap_pfault (frame=3D0xe7481a2c, usermode=3D0, e= va=3D3217022972) at /usr/src/sys/i386/i386/trap.c:843 > >> >>> #5 0xc08b3133 in trap (frame=3D0xe7481a2c) at /usr/src/sys/i386/i= 386/trap.c:562 > >> >>> #6 0xc089bedc in calltrap () at /usr/src/sys/i386/i386/exception.= s:168 > >> >>> #7 0xc50b396c in elf_linux_fixup (stack_base=3D0xe7481c0c, imgp= =3D0xe7481b98) at /usr/src/sys/modules/linux/../../i386/linux/linux_sysvec.= c:288 > >> >>> #8 0xc05ac636 in kern_execve (td=3D0xc5c24580, args=3D0xe7481c3c,= mac_p=3D0x0) at /usr/src/sys/kern/kern_exec.c:551 > >> >>> #9 0xc50ab387 in linux_execve (td=3D0xc5c24580, args=3D0xe7481cec= ) at /usr/src/sys/modules/linux/../../i386/linux/linux_machdep.c:143 > >> >>> #10 0xc08b2902 in syscall (frame=3D0xe7481d28) at subr_syscall.c:1= 14 > >> >>> #11 0xc089bf41 in Xint0x80_syscall () at /usr/src/sys/i386/i386/ex= ception.s:266 > >> >>> #12 0x00000033 in ?? () > >> >>>=20 > >> >> I am not sure if this is the real cause of your panic, but the line= from > >> >> the backtrace indeed has a bug. Please try the change below. > >> >> > >> >> diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linux_s= ysvec.c > >> >> index 7634138..d4e23e1 100644 > >> >> --- a/sys/i386/linux/linux_sysvec.c > >> >> +++ b/sys/i386/linux/linux_sysvec.c > >> >> @@ -227,11 +227,11 @@ linux_fixup(register_t **stack_base, struct i= mage_params *imgp) > >> >> argv =3D *stack_base; > >> >> envp =3D *stack_base + (imgp->args->argc + 1); > >> >> (*stack_base)--; > >> >> - **stack_base =3D (intptr_t)(void *)envp; > >> >> + suword(*stack_base, (intptr_t)(void *)envp); > >> >> (*stack_base)--; > >> >> - **stack_base =3D (intptr_t)(void *)argv; > >> >> + suword(*stack_base, (intptr_t)(void *)argv); > >> >> (*stack_base)--; > >> >> - **stack_base =3D imgp->args->argc; > >> >> + suword(*stack_base, imgp->args->argc); > >> >> return (0); > >> >> } > >> >> =20 > >> >> @@ -286,7 +286,7 @@ elf_linux_fixup(register_t **stack_base, struct= image_params *imgp) > >> >> imgp->auxargs =3D NULL; > >> >> =20 > >> >> (*stack_base)--; > >> >> - **stack_base =3D (register_t)imgp->args->argc; > >> >> + suword(*stack_base, (register_t)imgp->args->argc); > >> >> return (0); > >> >> } > >> >> =20 > >> > > >> > Thanks for the response! I will try the patch, but that file has not > >> > been touched since June 2011. I was suspecting the changes in r2311= 46 > >> > and r231148. If there is no change with your patch I will roll back > >> > those to see what happens. > > This is very unlikely. fadvise() has nothing to do with image activator= s. > > > >>=20 > >> No panics so far. That patch does indeed seem to solve the problem! I > >> also verified with going back to the old kernel, which again > >> consistently paniced. > > I will commit the change in minutes. Kernel must not access usermode > > addresses directly. > > > > But, does the application that used to panic the system, behave properl= y ? >=20 > Yes, it (acroread8) does behave properly with the patch. Have not > tested extensively, however. >=20 > >> Thanks very much for good work! > >>=20 > >> I'm a but puzzled though, because that bug must have been there for > >> quite some time without triggering the panic. > > The panic with unpatched kernel looks puzzling. Do you have some > > non-default stack limit ? Can you look at the resource limit values > > for the process initiated the panic ? >=20 > Not that I'm aware of. Unless the acroread launch script does this. I > don't know how to check this for a running process, but "limits|grep > stack" in a regular shell gives me: >=20 > stacksize 65536 kB >=20 > Or, do you mean that I can dig that out of the crash dump? If so, I'll > need some help with how to. =46rom the kgdb, frame 8, print the content of td->td_proc->p_limit. --D90rafnCA5jqK2oI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9Lk88ACgkQC3+MBN1Mb4he8wCfW7hp8fVbNpTSx8KEOrSpnnrF nGQAmwZsRS/L6QyJ/dTS/dFwrwoUwuNo =6PUh -----END PGP SIGNATURE----- --D90rafnCA5jqK2oI-- From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 27 14:35:51 2012 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F051065675 for ; Mon, 27 Feb 2012 14:35:51 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id CCA178FC1D for ; Mon, 27 Feb 2012 14:35:50 +0000 (UTC) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.4/8.14.4) with ESMTP id q1REZnno072578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Feb 2012 15:35:49 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.5/8.14.4) with ESMTP id q1REZsma004032; Mon, 27 Feb 2012 15:35:54 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.5/8.14.5/Submit) id q1REZstw004031; Mon, 27 Feb 2012 15:35:54 +0100 (CET) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: Konstantin Belousov In-Reply-To: <20120227143143.GE55074@deviant.kiev.zoral.com.ua> (Konstantin Belousov's message of "Mon, 27 Feb 2012 16:31:43 +0200") References: <20120224142940.GR55074@deviant.kiev.zoral.com.ua> <20120225011228.GB55074@deviant.kiev.zoral.com.ua> <20120227143143.GE55074@deviant.kiev.zoral.com.ua> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) Date: Mon, 27 Feb 2012 15:35:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emulation@freebsd.org Subject: Re: [Bengt Ahlgren] 8.3-PRERELEASE panic in linux emulation 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: Mon, 27 Feb 2012 14:35:51 -0000 Konstantin Belousov writes: > On Mon, Feb 27, 2012 at 01:49:28PM +0100, Bengt Ahlgren wrote: >> Konstantin Belousov writes: >> >> > On Fri, Feb 24, 2012 at 09:55:31PM +0100, Bengt Ahlgren wrote: >> >> Bengt Ahlgren writes: >> >> >> >> > Konstantin Belousov writes: >> >> > >> >> >> On Fri, Feb 24, 2012 at 01:27:24PM +0100, Bengt Ahlgren wrote: >> >> >>> Hello! >> >> >>> >> >> >>> Perhaps emulation@ is a better place to report this problem? >> >> >>> >> >> >>> Bengt >> >> >>> >> >> >> >> >> >>> From: Bengt Ahlgren >> >> >>> To: stable@freebsd.org >> >> >>> Subject: 8.3-PRERELEASE panic in linux emulation >> >> >>> Date: Thu, 23 Feb 2012 17:26:32 +0100 >> >> >>> >> >> >>> Hi! >> >> >>> >> >> >>> I get a consistent panic when starting acroread after updating to >> >> >>> 8.3-PRERELEASE. An 8.2-STABLE from Feb 4th was OK. Can provide more >> >> >>> info if needed. >> >> >>> >> >> >>> Bengt >> >> >>> >> >> >>> FreeBSD xx.yy.zz 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #13 r231999: Wed Feb 22 21:01:38 CET 2012 bengta@P142.sics.se:/usr/obj/usr/src/sys/P142-82 i386 >> >> >>> >> >> >>> Fatal trap 12: page fault while in kernel mode >> >> >>> fault virtual address = 0xbfbfdffc >> >> >>> fault code = supervisor write, page not present >> >> >>> instruction pointer = 0x20:0xc50b396c >> >> >>> stack pointer = 0x28:0xe7481a6c >> >> >>> frame pointer = 0x28:0xe7481a90 >> >> >>> code segment = base 0x0, limit 0xfffff, type 0x1b >> >> >>> = DPL 0, pres 1, def32 1, gran 1 >> >> >>> processor eflags = interrupt enabled, resume, IOPL = 0 >> >> >>> current process = 1997 (bash) >> >> >>> trap number = 12 >> >> >>> panic: page fault >> >> >>> KDB: stack backtrace: >> >> >>> db_trace_self_wrapper(c091af2a,70797420,78302065,a0d6231,c5d6b600,...) at db_trace_self_wrapper+0x26 >> >> >>> kdb_backtrace(c0919061,c09b49a0,c0900251,e7481910,e7481910,...) at kdb_backtrace+0x2a >> >> >>> panic(c0900251,c0941cab,c5c246e8,1,1,...) at panic+0xaf >> >> >>> trap_fatal(c0670d02,0,e7481964,80400,c5c24580,...) at trap_fatal+0x353 >> >> >>> trap_pfault(e74819cc,bfbfe190,c5c24580,202,c5cecac0,...) at trap_pfault+0x87 >> >> >>> trap(e7481a2c) at trap+0x453 >> >> >>> calltrap() at calltrap+0x6 >> >> >>> --- trap 0xc, eip = 0xc50b396c, esp = 0xe7481a6c, ebp = 0xe7481a90 --- >> >> >>> elf_linux_fixup(e7481c0c,e7481b98,c065ca92,c60ffce8,100000,...) at elf_linux_fixup+0x33c >> >> >>> kern_execve(c5c24580,e7481c3c,0,8112710,8116cd8,...) at kern_execve+0x7d6 >> >> >>> linux_execve(c5c24580,e7481cec,c,c,c,...) at linux_execve+0xa7 >> >> >>> syscall(e7481d28) at syscall+0x372 >> >> >>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >> >> >>> --- syscall (11, Linux ELF, linux_execve), eip = 0x281e0d4a, esp = 0xbfbfd644, ebp = 0xbfbfd7e8 --- >> >> >>> >> >> >>> #0 doadump () at pcpu.h:244 >> >> >>> #1 0xc05de609 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:441 >> >> >>> #2 0xc05de84f in panic (fmt=Variable "fmt" is not available. >> >> >>> ) at /usr/src/sys/kern/kern_shutdown.c:614 >> >> >>> #3 0xc08b22c3 in trap_fatal (frame=0xe7481a2c, eva=3217022972) at /usr/src/sys/i386/i386/trap.c:981 >> >> >>> #4 0xc08b2357 in trap_pfault (frame=0xe7481a2c, usermode=0, eva=3217022972) at /usr/src/sys/i386/i386/trap.c:843 >> >> >>> #5 0xc08b3133 in trap (frame=0xe7481a2c) at /usr/src/sys/i386/i386/trap.c:562 >> >> >>> #6 0xc089bedc in calltrap () at /usr/src/sys/i386/i386/exception.s:168 >> >> >>> #7 0xc50b396c in elf_linux_fixup (stack_base=0xe7481c0c, imgp=0xe7481b98) at /usr/src/sys/modules/linux/../../i386/linux/linux_sysvec.c:288 >> >> >>> #8 0xc05ac636 in kern_execve (td=0xc5c24580, args=0xe7481c3c, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:551 >> >> >>> #9 0xc50ab387 in linux_execve (td=0xc5c24580, args=0xe7481cec) at /usr/src/sys/modules/linux/../../i386/linux/linux_machdep.c:143 >> >> >>> #10 0xc08b2902 in syscall (frame=0xe7481d28) at subr_syscall.c:114 >> >> >>> #11 0xc089bf41 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 >> >> >>> #12 0x00000033 in ?? () >> >> >>> >> >> >> I am not sure if this is the real cause of your panic, but the line from >> >> >> the backtrace indeed has a bug. Please try the change below. >> >> >> >> >> >> diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linux_sysvec.c >> >> >> index 7634138..d4e23e1 100644 >> >> >> --- a/sys/i386/linux/linux_sysvec.c >> >> >> +++ b/sys/i386/linux/linux_sysvec.c >> >> >> @@ -227,11 +227,11 @@ linux_fixup(register_t **stack_base, struct image_params *imgp) >> >> >> argv = *stack_base; >> >> >> envp = *stack_base + (imgp->args->argc + 1); >> >> >> (*stack_base)--; >> >> >> - **stack_base = (intptr_t)(void *)envp; >> >> >> + suword(*stack_base, (intptr_t)(void *)envp); >> >> >> (*stack_base)--; >> >> >> - **stack_base = (intptr_t)(void *)argv; >> >> >> + suword(*stack_base, (intptr_t)(void *)argv); >> >> >> (*stack_base)--; >> >> >> - **stack_base = imgp->args->argc; >> >> >> + suword(*stack_base, imgp->args->argc); >> >> >> return (0); >> >> >> } >> >> >> >> >> >> @@ -286,7 +286,7 @@ elf_linux_fixup(register_t **stack_base, struct image_params *imgp) >> >> >> imgp->auxargs = NULL; >> >> >> >> >> >> (*stack_base)--; >> >> >> - **stack_base = (register_t)imgp->args->argc; >> >> >> + suword(*stack_base, (register_t)imgp->args->argc); >> >> >> return (0); >> >> >> } >> >> >> >> >> > >> >> > Thanks for the response! I will try the patch, but that file has not >> >> > been touched since June 2011. I was suspecting the changes in r231146 >> >> > and r231148. If there is no change with your patch I will roll back >> >> > those to see what happens. >> > This is very unlikely. fadvise() has nothing to do with image activators. >> > >> >> >> >> No panics so far. That patch does indeed seem to solve the problem! I >> >> also verified with going back to the old kernel, which again >> >> consistently paniced. >> > I will commit the change in minutes. Kernel must not access usermode >> > addresses directly. >> > >> > But, does the application that used to panic the system, behave properly ? >> >> Yes, it (acroread8) does behave properly with the patch. Have not >> tested extensively, however. >> >> >> Thanks very much for good work! >> >> >> >> I'm a but puzzled though, because that bug must have been there for >> >> quite some time without triggering the panic. >> > The panic with unpatched kernel looks puzzling. Do you have some >> > non-default stack limit ? Can you look at the resource limit values >> > for the process initiated the panic ? >> >> Not that I'm aware of. Unless the acroread launch script does this. I >> don't know how to check this for a running process, but "limits|grep >> stack" in a regular shell gives me: >> >> stacksize 65536 kB >> >> Or, do you mean that I can dig that out of the crash dump? If so, I'll >> need some help with how to. > > From the kgdb, frame 8, print the content of td->td_proc->p_limit. Is this it? (kgdb) frame 8 #8 0xc05ac636 in kern_execve (td=0xc5dc3000, args=0xe7535c3c, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:551 551 (*p->p_sysent->sv_fixup)(&stack_base, imgp); (kgdb) print td->td_proc->p_limit $1 = (struct plimit *) 0xc5490700 (kgdb) print *td->td_proc->p_limit $2 = {pl_rlimit = {{rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, {rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, {rlim_cur = 536870912, rlim_max = 536870912}, {rlim_cur = 67108864, rlim_max = 67108864}, { rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { rlim_cur = 5547, rlim_max = 5547}, {rlim_cur = 11095, rlim_max = 11095}, {rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}}, pl_refcnt = 51} Bengt From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 27 14:40:06 2012 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52549106566B for ; Mon, 27 Feb 2012 14:40:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A51658FC14 for ; Mon, 27 Feb 2012 14:40:05 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1REdwwS086297; Mon, 27 Feb 2012 16:39:58 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1REdwBF009069; Mon, 27 Feb 2012 16:39:58 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1REdwMk009068; Mon, 27 Feb 2012 16:39:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 Feb 2012 16:39:58 +0200 From: Konstantin Belousov To: Bengt Ahlgren Message-ID: <20120227143958.GG55074@deviant.kiev.zoral.com.ua> References: <20120224142940.GR55074@deviant.kiev.zoral.com.ua> <20120225011228.GB55074@deviant.kiev.zoral.com.ua> <20120227143143.GE55074@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QMBzfVONVaIN0ukq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: emulation@freebsd.org Subject: Re: [Bengt Ahlgren] 8.3-PRERELEASE panic in linux emulation 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: Mon, 27 Feb 2012 14:40:06 -0000 --QMBzfVONVaIN0ukq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 27, 2012 at 03:35:54PM +0100, Bengt Ahlgren wrote: > Konstantin Belousov writes: >=20 > > On Mon, Feb 27, 2012 at 01:49:28PM +0100, Bengt Ahlgren wrote: > >> Konstantin Belousov writes: > >>=20 > >> > On Fri, Feb 24, 2012 at 09:55:31PM +0100, Bengt Ahlgren wrote: > >> >> Bengt Ahlgren writes: > >> >>=20 > >> >> > Konstantin Belousov writes: > >> >> > > >> >> >> On Fri, Feb 24, 2012 at 01:27:24PM +0100, Bengt Ahlgren wrote: > >> >> >>> Hello! > >> >> >>>=20 > >> >> >>> Perhaps emulation@ is a better place to report this problem? > >> >> >>>=20 > >> >> >>> Bengt > >> >> >>>=20 > >> >> >> > >> >> >>> From: Bengt Ahlgren > >> >> >>> To: stable@freebsd.org > >> >> >>> Subject: 8.3-PRERELEASE panic in linux emulation > >> >> >>> Date: Thu, 23 Feb 2012 17:26:32 +0100 > >> >> >>>=20 > >> >> >>> Hi! > >> >> >>>=20 > >> >> >>> I get a consistent panic when starting acroread after updating = to > >> >> >>> 8.3-PRERELEASE. An 8.2-STABLE from Feb 4th was OK. Can provid= e more > >> >> >>> info if needed. > >> >> >>>=20 > >> >> >>> Bengt > >> >> >>>=20 > >> >> >>> FreeBSD xx.yy.zz 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #13 r231= 999: Wed Feb 22 21:01:38 CET 2012 bengta@P142.sics.se:/usr/obj/usr/src/= sys/P142-82 i386 > >> >> >>>=20 > >> >> >>> Fatal trap 12: page fault while in kernel mode > >> >> >>> fault virtual address =3D 0xbfbfdffc > >> >> >>> fault code =3D supervisor write, page not present > >> >> >>> instruction pointer =3D 0x20:0xc50b396c > >> >> >>> stack pointer =3D 0x28:0xe7481a6c > >> >> >>> frame pointer =3D 0x28:0xe7481a90 > >> >> >>> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >> >> >>> =3D DPL 0, pres 1, def32 1, gran 1 > >> >> >>> processor eflags =3D interrupt enabled, resume, IOPL =3D= 0 > >> >> >>> current process =3D 1997 (bash) > >> >> >>> trap number =3D 12 > >> >> >>> panic: page fault > >> >> >>> KDB: stack backtrace: > >> >> >>> db_trace_self_wrapper(c091af2a,70797420,78302065,a0d6231,c5d6b6= 00,...) at db_trace_self_wrapper+0x26 > >> >> >>> kdb_backtrace(c0919061,c09b49a0,c0900251,e7481910,e7481910,...)= at kdb_backtrace+0x2a > >> >> >>> panic(c0900251,c0941cab,c5c246e8,1,1,...) at panic+0xaf > >> >> >>> trap_fatal(c0670d02,0,e7481964,80400,c5c24580,...) at trap_fata= l+0x353 > >> >> >>> trap_pfault(e74819cc,bfbfe190,c5c24580,202,c5cecac0,...) at tra= p_pfault+0x87 > >> >> >>> trap(e7481a2c) at trap+0x453 > >> >> >>> calltrap() at calltrap+0x6 > >> >> >>> --- trap 0xc, eip =3D 0xc50b396c, esp =3D 0xe7481a6c, ebp =3D 0= xe7481a90 --- > >> >> >>> elf_linux_fixup(e7481c0c,e7481b98,c065ca92,c60ffce8,100000,...)= at elf_linux_fixup+0x33c > >> >> >>> kern_execve(c5c24580,e7481c3c,0,8112710,8116cd8,...) at kern_ex= ecve+0x7d6 > >> >> >>> linux_execve(c5c24580,e7481cec,c,c,c,...) at linux_execve+0xa7 > >> >> >>> syscall(e7481d28) at syscall+0x372 > >> >> >>> Xint0x80_syscall() at Xint0x80_syscall+0x21 > >> >> >>> --- syscall (11, Linux ELF, linux_execve), eip =3D 0x281e0d4a, = esp =3D 0xbfbfd644, ebp =3D 0xbfbfd7e8 --- > >> >> >>>=20 > >> >> >>> #0 doadump () at pcpu.h:244 > >> >> >>> #1 0xc05de609 in boot (howto=3D260) at /usr/src/sys/kern/kern_= shutdown.c:441 > >> >> >>> #2 0xc05de84f in panic (fmt=3DVariable "fmt" is not available. > >> >> >>> ) at /usr/src/sys/kern/kern_shutdown.c:614 > >> >> >>> #3 0xc08b22c3 in trap_fatal (frame=3D0xe7481a2c, eva=3D3217022= 972) at /usr/src/sys/i386/i386/trap.c:981 > >> >> >>> #4 0xc08b2357 in trap_pfault (frame=3D0xe7481a2c, usermode=3D0= , eva=3D3217022972) at /usr/src/sys/i386/i386/trap.c:843 > >> >> >>> #5 0xc08b3133 in trap (frame=3D0xe7481a2c) at /usr/src/sys/i38= 6/i386/trap.c:562 > >> >> >>> #6 0xc089bedc in calltrap () at /usr/src/sys/i386/i386/excepti= on.s:168 > >> >> >>> #7 0xc50b396c in elf_linux_fixup (stack_base=3D0xe7481c0c, img= p=3D0xe7481b98) at /usr/src/sys/modules/linux/../../i386/linux/linux_sysvec= .c:288 > >> >> >>> #8 0xc05ac636 in kern_execve (td=3D0xc5c24580, args=3D0xe7481c= 3c, mac_p=3D0x0) at /usr/src/sys/kern/kern_exec.c:551 > >> >> >>> #9 0xc50ab387 in linux_execve (td=3D0xc5c24580, args=3D0xe7481= cec) at /usr/src/sys/modules/linux/../../i386/linux/linux_machdep.c:143 > >> >> >>> #10 0xc08b2902 in syscall (frame=3D0xe7481d28) at subr_syscall.= c:114 > >> >> >>> #11 0xc089bf41 in Xint0x80_syscall () at /usr/src/sys/i386/i386= /exception.s:266 > >> >> >>> #12 0x00000033 in ?? () > >> >> >>>=20 > >> >> >> I am not sure if this is the real cause of your panic, but the l= ine from > >> >> >> the backtrace indeed has a bug. Please try the change below. > >> >> >> > >> >> >> diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linu= x_sysvec.c > >> >> >> index 7634138..d4e23e1 100644 > >> >> >> --- a/sys/i386/linux/linux_sysvec.c > >> >> >> +++ b/sys/i386/linux/linux_sysvec.c > >> >> >> @@ -227,11 +227,11 @@ linux_fixup(register_t **stack_base, struc= t image_params *imgp) > >> >> >> argv =3D *stack_base; > >> >> >> envp =3D *stack_base + (imgp->args->argc + 1); > >> >> >> (*stack_base)--; > >> >> >> - **stack_base =3D (intptr_t)(void *)envp; > >> >> >> + suword(*stack_base, (intptr_t)(void *)envp); > >> >> >> (*stack_base)--; > >> >> >> - **stack_base =3D (intptr_t)(void *)argv; > >> >> >> + suword(*stack_base, (intptr_t)(void *)argv); > >> >> >> (*stack_base)--; > >> >> >> - **stack_base =3D imgp->args->argc; > >> >> >> + suword(*stack_base, imgp->args->argc); > >> >> >> return (0); > >> >> >> } > >> >> >> =20 > >> >> >> @@ -286,7 +286,7 @@ elf_linux_fixup(register_t **stack_base, str= uct image_params *imgp) > >> >> >> imgp->auxargs =3D NULL; > >> >> >> =20 > >> >> >> (*stack_base)--; > >> >> >> - **stack_base =3D (register_t)imgp->args->argc; > >> >> >> + suword(*stack_base, (register_t)imgp->args->argc); > >> >> >> return (0); > >> >> >> } > >> >> >> =20 > >> >> > > >> >> > Thanks for the response! I will try the patch, but that file has= not > >> >> > been touched since June 2011. I was suspecting the changes in r2= 31146 > >> >> > and r231148. If there is no change with your patch I will roll b= ack > >> >> > those to see what happens. > >> > This is very unlikely. fadvise() has nothing to do with image activa= tors. > >> > > >> >>=20 > >> >> No panics so far. That patch does indeed seem to solve the problem= ! I > >> >> also verified with going back to the old kernel, which again > >> >> consistently paniced. > >> > I will commit the change in minutes. Kernel must not access usermode > >> > addresses directly. > >> > > >> > But, does the application that used to panic the system, behave prop= erly ? > >>=20 > >> Yes, it (acroread8) does behave properly with the patch. Have not > >> tested extensively, however. > >>=20 > >> >> Thanks very much for good work! > >> >>=20 > >> >> I'm a but puzzled though, because that bug must have been there for > >> >> quite some time without triggering the panic. > >> > The panic with unpatched kernel looks puzzling. Do you have some > >> > non-default stack limit ? Can you look at the resource limit values > >> > for the process initiated the panic ? > >>=20 > >> Not that I'm aware of. Unless the acroread launch script does this. I > >> don't know how to check this for a running process, but "limits|grep > >> stack" in a regular shell gives me: > >>=20 > >> stacksize 65536 kB > >>=20 > >> Or, do you mean that I can dig that out of the crash dump? If so, I'll > >> need some help with how to. > > > > From the kgdb, frame 8, print the content of td->td_proc->p_limit. >=20 > Is this it? >=20 > (kgdb) frame 8 > #8 0xc05ac636 in kern_execve (td=3D0xc5dc3000, args=3D0xe7535c3c, mac_p= =3D0x0) > at /usr/src/sys/kern/kern_exec.c:551 > 551 (*p->p_sysent->sv_fixup)(&stack_base, imgp); > (kgdb) print td->td_proc->p_limit > $1 =3D (struct plimit *) 0xc5490700 > (kgdb) print *td->td_proc->p_limit > $2 =3D {pl_rlimit =3D {{rlim_cur =3D 9223372036854775807,=20 > rlim_max =3D 9223372036854775807}, {rlim_cur =3D 922337203685477580= 7,=20 > rlim_max =3D 9223372036854775807}, {rlim_cur =3D 536870912,=20 > rlim_max =3D 536870912}, {rlim_cur =3D 67108864, rlim_max =3D 67108= 864}, { > rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807}= , { > rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807}= , { > rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807}= , { > rlim_cur =3D 5547, rlim_max =3D 5547}, {rlim_cur =3D 11095, rlim_ma= x =3D 11095},=20 > {rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807},= { > rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807}= , { > rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807}= , { > rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807}= },=20 > pl_refcnt =3D 51} Yes, but the stack size is the normal 64MB. Did other linux binaries worked before the patch ? E.g., did the bash started normally ? --QMBzfVONVaIN0ukq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9Llb4ACgkQC3+MBN1Mb4iNnwCgoFjELYcKUAQ/4EViRLiY+dIs AHwAnRYM1Mt0bVEtappdoZVdaeG8e4wy =gZvC -----END PGP SIGNATURE----- --QMBzfVONVaIN0ukq-- From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 27 14:50:37 2012 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D00421065672 for ; Mon, 27 Feb 2012 14:50:37 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id 4162B8FC17 for ; Mon, 27 Feb 2012 14:50:36 +0000 (UTC) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by sink.sics.se (8.14.4/8.14.4) with ESMTP id q1REoZLl072601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Feb 2012 15:50:35 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.5/8.14.4) with ESMTP id q1REoeR6004079; Mon, 27 Feb 2012 15:50:40 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.5/8.14.5/Submit) id q1REoe79004078; Mon, 27 Feb 2012 15:50:40 +0100 (CET) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: Konstantin Belousov In-Reply-To: <20120227143958.GG55074@deviant.kiev.zoral.com.ua> (Konstantin Belousov's message of "Mon, 27 Feb 2012 16:39:58 +0200") References: <20120224142940.GR55074@deviant.kiev.zoral.com.ua> <20120225011228.GB55074@deviant.kiev.zoral.com.ua> <20120227143143.GE55074@deviant.kiev.zoral.com.ua> <20120227143958.GG55074@deviant.kiev.zoral.com.ua> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) Date: Mon, 27 Feb 2012 15:50:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emulation@freebsd.org Subject: Re: [Bengt Ahlgren] 8.3-PRERELEASE panic in linux emulation 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: Mon, 27 Feb 2012 14:50:38 -0000 Konstantin Belousov writes: > On Mon, Feb 27, 2012 at 03:35:54PM +0100, Bengt Ahlgren wrote: >> Konstantin Belousov writes: >> >> > On Mon, Feb 27, 2012 at 01:49:28PM +0100, Bengt Ahlgren wrote: >> >> Konstantin Belousov writes: >> >> >> >> > On Fri, Feb 24, 2012 at 09:55:31PM +0100, Bengt Ahlgren wrote: >> >> >> Bengt Ahlgren writes: >> >> >> >> >> >> > Konstantin Belousov writes: >> >> >> > >> >> >> >> On Fri, Feb 24, 2012 at 01:27:24PM +0100, Bengt Ahlgren wrote: >> >> >> >>> Hello! >> >> >> >>> >> >> >> >>> Perhaps emulation@ is a better place to report this problem? >> >> >> >>> >> >> >> >>> Bengt >> >> >> >>> >> >> >> >> >> >> >> >>> From: Bengt Ahlgren >> >> >> >>> To: stable@freebsd.org >> >> >> >>> Subject: 8.3-PRERELEASE panic in linux emulation >> >> >> >>> Date: Thu, 23 Feb 2012 17:26:32 +0100 >> >> >> >>> >> >> >> >>> Hi! >> >> >> >>> >> >> >> >>> I get a consistent panic when starting acroread after updating to >> >> >> >>> 8.3-PRERELEASE. An 8.2-STABLE from Feb 4th was OK. Can provide more >> >> >> >>> info if needed. >> >> >> >>> >> >> >> >>> Bengt >> >> >> >>> >> >> >> >>> FreeBSD xx.yy.zz 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #13 r231999: Wed Feb 22 21:01:38 CET 2012 bengta@P142.sics.se:/usr/obj/usr/src/sys/P142-82 i386 >> >> >> >>> >> >> >> >>> Fatal trap 12: page fault while in kernel mode >> >> >> >>> fault virtual address = 0xbfbfdffc >> >> >> >>> fault code = supervisor write, page not present >> >> >> >>> instruction pointer = 0x20:0xc50b396c >> >> >> >>> stack pointer = 0x28:0xe7481a6c >> >> >> >>> frame pointer = 0x28:0xe7481a90 >> >> >> >>> code segment = base 0x0, limit 0xfffff, type 0x1b >> >> >> >>> = DPL 0, pres 1, def32 1, gran 1 >> >> >> >>> processor eflags = interrupt enabled, resume, IOPL = 0 >> >> >> >>> current process = 1997 (bash) >> >> >> >>> trap number = 12 >> >> >> >>> panic: page fault >> >> >> >>> KDB: stack backtrace: >> >> >> >>> db_trace_self_wrapper(c091af2a,70797420,78302065,a0d6231,c5d6b600,...) at db_trace_self_wrapper+0x26 >> >> >> >>> kdb_backtrace(c0919061,c09b49a0,c0900251,e7481910,e7481910,...) at kdb_backtrace+0x2a >> >> >> >>> panic(c0900251,c0941cab,c5c246e8,1,1,...) at panic+0xaf >> >> >> >>> trap_fatal(c0670d02,0,e7481964,80400,c5c24580,...) at trap_fatal+0x353 >> >> >> >>> trap_pfault(e74819cc,bfbfe190,c5c24580,202,c5cecac0,...) at trap_pfault+0x87 >> >> >> >>> trap(e7481a2c) at trap+0x453 >> >> >> >>> calltrap() at calltrap+0x6 >> >> >> >>> --- trap 0xc, eip = 0xc50b396c, esp = 0xe7481a6c, ebp = 0xe7481a90 --- >> >> >> >>> elf_linux_fixup(e7481c0c,e7481b98,c065ca92,c60ffce8,100000,...) at elf_linux_fixup+0x33c >> >> >> >>> kern_execve(c5c24580,e7481c3c,0,8112710,8116cd8,...) at kern_execve+0x7d6 >> >> >> >>> linux_execve(c5c24580,e7481cec,c,c,c,...) at linux_execve+0xa7 >> >> >> >>> syscall(e7481d28) at syscall+0x372 >> >> >> >>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >> >> >> >>> --- syscall (11, Linux ELF, linux_execve), eip = 0x281e0d4a, esp = 0xbfbfd644, ebp = 0xbfbfd7e8 --- >> >> >> >>> >> >> >> >>> #0 doadump () at pcpu.h:244 >> >> >> >>> #1 0xc05de609 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:441 >> >> >> >>> #2 0xc05de84f in panic (fmt=Variable "fmt" is not available. >> >> >> >>> ) at /usr/src/sys/kern/kern_shutdown.c:614 >> >> >> >>> #3 0xc08b22c3 in trap_fatal (frame=0xe7481a2c, eva=3217022972) at /usr/src/sys/i386/i386/trap.c:981 >> >> >> >>> #4 0xc08b2357 in trap_pfault (frame=0xe7481a2c, usermode=0, eva=3217022972) at /usr/src/sys/i386/i386/trap.c:843 >> >> >> >>> #5 0xc08b3133 in trap (frame=0xe7481a2c) at /usr/src/sys/i386/i386/trap.c:562 >> >> >> >>> #6 0xc089bedc in calltrap () at /usr/src/sys/i386/i386/exception.s:168 >> >> >> >>> #7 0xc50b396c in elf_linux_fixup (stack_base=0xe7481c0c, imgp=0xe7481b98) at /usr/src/sys/modules/linux/../../i386/linux/linux_sysvec.c:288 >> >> >> >>> #8 0xc05ac636 in kern_execve (td=0xc5c24580, args=0xe7481c3c, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:551 >> >> >> >>> #9 0xc50ab387 in linux_execve (td=0xc5c24580, args=0xe7481cec) at /usr/src/sys/modules/linux/../../i386/linux/linux_machdep.c:143 >> >> >> >>> #10 0xc08b2902 in syscall (frame=0xe7481d28) at subr_syscall.c:114 >> >> >> >>> #11 0xc089bf41 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 >> >> >> >>> #12 0x00000033 in ?? () >> >> >> >>> >> >> >> >> I am not sure if this is the real cause of your panic, but the line from >> >> >> >> the backtrace indeed has a bug. Please try the change below. >> >> >> >> >> >> >> >> diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linux_sysvec.c >> >> >> >> index 7634138..d4e23e1 100644 >> >> >> >> --- a/sys/i386/linux/linux_sysvec.c >> >> >> >> +++ b/sys/i386/linux/linux_sysvec.c >> >> >> >> @@ -227,11 +227,11 @@ linux_fixup(register_t **stack_base, struct image_params *imgp) >> >> >> >> argv = *stack_base; >> >> >> >> envp = *stack_base + (imgp->args->argc + 1); >> >> >> >> (*stack_base)--; >> >> >> >> - **stack_base = (intptr_t)(void *)envp; >> >> >> >> + suword(*stack_base, (intptr_t)(void *)envp); >> >> >> >> (*stack_base)--; >> >> >> >> - **stack_base = (intptr_t)(void *)argv; >> >> >> >> + suword(*stack_base, (intptr_t)(void *)argv); >> >> >> >> (*stack_base)--; >> >> >> >> - **stack_base = imgp->args->argc; >> >> >> >> + suword(*stack_base, imgp->args->argc); >> >> >> >> return (0); >> >> >> >> } >> >> >> >> >> >> >> >> @@ -286,7 +286,7 @@ elf_linux_fixup(register_t **stack_base, struct image_params *imgp) >> >> >> >> imgp->auxargs = NULL; >> >> >> >> >> >> >> >> (*stack_base)--; >> >> >> >> - **stack_base = (register_t)imgp->args->argc; >> >> >> >> + suword(*stack_base, (register_t)imgp->args->argc); >> >> >> >> return (0); >> >> >> >> } >> >> >> >> >> >> >> > >> >> >> > Thanks for the response! I will try the patch, but that file has not >> >> >> > been touched since June 2011. I was suspecting the changes in r231146 >> >> >> > and r231148. If there is no change with your patch I will roll back >> >> >> > those to see what happens. >> >> > This is very unlikely. fadvise() has nothing to do with image activators. >> >> > >> >> >> >> >> >> No panics so far. That patch does indeed seem to solve the problem! I >> >> >> also verified with going back to the old kernel, which again >> >> >> consistently paniced. >> >> > I will commit the change in minutes. Kernel must not access usermode >> >> > addresses directly. >> >> > >> >> > But, does the application that used to panic the system, behave properly ? >> >> >> >> Yes, it (acroread8) does behave properly with the patch. Have not >> >> tested extensively, however. >> >> >> >> >> Thanks very much for good work! >> >> >> >> >> >> I'm a but puzzled though, because that bug must have been there for >> >> >> quite some time without triggering the panic. >> >> > The panic with unpatched kernel looks puzzling. Do you have some >> >> > non-default stack limit ? Can you look at the resource limit values >> >> > for the process initiated the panic ? >> >> >> >> Not that I'm aware of. Unless the acroread launch script does this. I >> >> don't know how to check this for a running process, but "limits|grep >> >> stack" in a regular shell gives me: >> >> >> >> stacksize 65536 kB >> >> >> >> Or, do you mean that I can dig that out of the crash dump? If so, I'll >> >> need some help with how to. >> > >> > From the kgdb, frame 8, print the content of td->td_proc->p_limit. >> >> Is this it? >> >> (kgdb) frame 8 >> #8 0xc05ac636 in kern_execve (td=0xc5dc3000, args=0xe7535c3c, mac_p=0x0) >> at /usr/src/sys/kern/kern_exec.c:551 >> 551 (*p->p_sysent->sv_fixup)(&stack_base, imgp); >> (kgdb) print td->td_proc->p_limit >> $1 = (struct plimit *) 0xc5490700 >> (kgdb) print *td->td_proc->p_limit >> $2 = {pl_rlimit = {{rlim_cur = 9223372036854775807, >> rlim_max = 9223372036854775807}, {rlim_cur = 9223372036854775807, >> rlim_max = 9223372036854775807}, {rlim_cur = 536870912, >> rlim_max = 536870912}, {rlim_cur = 67108864, rlim_max = 67108864}, { >> rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { >> rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { >> rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { >> rlim_cur = 5547, rlim_max = 5547}, {rlim_cur = 11095, rlim_max = 11095}, >> {rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { >> rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { >> rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { >> rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}}, >> pl_refcnt = 51} > Yes, but the stack size is the normal 64MB. > > Did other linux binaries worked before the patch ? E.g., did the bash > started normally ? Hmm, I see now that the crash dump actually says that it is bash that is running, not acroread. The acroread startup script invokes a linux bash to launch the acroread binary, so I guess acroread was actually never started. I should also say that I was running KDE. I can test invoking linux bash and some other linux utilities without any Xorg+KDE to see what happens. I however don't have time today for this. Bengt From owner-freebsd-emulation@FreeBSD.ORG Tue Feb 28 09:54:45 2012 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F3AE106573F for ; Tue, 28 Feb 2012 09:54:45 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 67EB98FC19 for ; Tue, 28 Feb 2012 09:54:44 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q1S9edl6017234 for ; Tue, 28 Feb 2012 01:40:41 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <4F4CA10E.3070508@rawbw.com> Date: Tue, 28 Feb 2012 01:40:30 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: emulation@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Why ldd(1) launches linux apps? 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, 28 Feb 2012 09:54:45 -0000 I noticed the strange thing. ldd(1) launches all linux apps I tried (skype, acroread9). And it doesn't launch BSD apps. Is this a knows issue? Yuri From owner-freebsd-emulation@FreeBSD.ORG Tue Feb 28 16:22:41 2012 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12FFF106564A for ; Tue, 28 Feb 2012 16:22:41 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from sink.sics.se (sink.sics.se [193.10.64.88]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD5B8FC08 for ; Tue, 28 Feb 2012 16:22:39 +0000 (UTC) Received: from P142.sics.se (h139n3-u-d1.ias.bredband.telia.com [90.228.197.139]) by sink.sics.se (8.14.4/8.14.4) with ESMTP id q1SGMb6o075730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Feb 2012 17:22:38 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.14.5/8.14.4) with ESMTP id q1SGMc01004760; Tue, 28 Feb 2012 17:22:38 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.14.5/8.14.5/Submit) id q1SGMcTD004759; Tue, 28 Feb 2012 17:22:38 +0100 (CET) (envelope-from bengta@P142.sics.se) From: Bengt Ahlgren To: Konstantin Belousov In-Reply-To: (Bengt Ahlgren's message of "Mon, 27 Feb 2012 15:50:40 +0100") References: <20120224142940.GR55074@deviant.kiev.zoral.com.ua> <20120225011228.GB55074@deviant.kiev.zoral.com.ua> <20120227143143.GE55074@deviant.kiev.zoral.com.ua> <20120227143958.GG55074@deviant.kiev.zoral.com.ua> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) Date: Tue, 28 Feb 2012 17:22:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emulation@freebsd.org Subject: Re: [Bengt Ahlgren] 8.3-PRERELEASE panic in linux emulation 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, 28 Feb 2012 16:22:41 -0000 Bengt Ahlgren writes: > Konstantin Belousov writes: > >> On Mon, Feb 27, 2012 at 03:35:54PM +0100, Bengt Ahlgren wrote: >>> Konstantin Belousov writes: >>> >>> > On Mon, Feb 27, 2012 at 01:49:28PM +0100, Bengt Ahlgren wrote: >>> >> Konstantin Belousov writes: >>> >> >>> >> > On Fri, Feb 24, 2012 at 09:55:31PM +0100, Bengt Ahlgren wrote: >>> >> >> Bengt Ahlgren writes: >>> >> >> >>> >> >> > Konstantin Belousov writes: >>> >> >> > >>> >> >> >> On Fri, Feb 24, 2012 at 01:27:24PM +0100, Bengt Ahlgren wrote: >>> >> >> >>> Hello! >>> >> >> >>> >>> >> >> >>> Perhaps emulation@ is a better place to report this problem? >>> >> >> >>> >>> >> >> >>> Bengt >>> >> >> >>> >>> >> >> >> >>> >> >> >>> From: Bengt Ahlgren >>> >> >> >>> To: stable@freebsd.org >>> >> >> >>> Subject: 8.3-PRERELEASE panic in linux emulation >>> >> >> >>> Date: Thu, 23 Feb 2012 17:26:32 +0100 >>> >> >> >>> >>> >> >> >>> Hi! >>> >> >> >>> >>> >> >> >>> I get a consistent panic when starting acroread after updating to >>> >> >> >>> 8.3-PRERELEASE. An 8.2-STABLE from Feb 4th was OK. Can provide more >>> >> >> >>> info if needed. >>> >> >> >>> >>> >> >> >>> Bengt >>> >> >> >>> >>> >> >> >>> FreeBSD xx.yy.zz 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #13 r231999: Wed Feb 22 21:01:38 CET 2012 bengta@P142.sics.se:/usr/obj/usr/src/sys/P142-82 i386 >>> >> >> >>> >>> >> >> >>> Fatal trap 12: page fault while in kernel mode >>> >> >> >>> fault virtual address = 0xbfbfdffc >>> >> >> >>> fault code = supervisor write, page not present >>> >> >> >>> instruction pointer = 0x20:0xc50b396c >>> >> >> >>> stack pointer = 0x28:0xe7481a6c >>> >> >> >>> frame pointer = 0x28:0xe7481a90 >>> >> >> >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> >> >> >>> = DPL 0, pres 1, def32 1, gran 1 >>> >> >> >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> >> >> >>> current process = 1997 (bash) >>> >> >> >>> trap number = 12 >>> >> >> >>> panic: page fault >>> >> >> >>> KDB: stack backtrace: >>> >> >> >>> db_trace_self_wrapper(c091af2a,70797420,78302065,a0d6231,c5d6b600,...) at db_trace_self_wrapper+0x26 >>> >> >> >>> kdb_backtrace(c0919061,c09b49a0,c0900251,e7481910,e7481910,...) at kdb_backtrace+0x2a >>> >> >> >>> panic(c0900251,c0941cab,c5c246e8,1,1,...) at panic+0xaf >>> >> >> >>> trap_fatal(c0670d02,0,e7481964,80400,c5c24580,...) at trap_fatal+0x353 >>> >> >> >>> trap_pfault(e74819cc,bfbfe190,c5c24580,202,c5cecac0,...) at trap_pfault+0x87 >>> >> >> >>> trap(e7481a2c) at trap+0x453 >>> >> >> >>> calltrap() at calltrap+0x6 >>> >> >> >>> --- trap 0xc, eip = 0xc50b396c, esp = 0xe7481a6c, ebp = 0xe7481a90 --- >>> >> >> >>> elf_linux_fixup(e7481c0c,e7481b98,c065ca92,c60ffce8,100000,...) at elf_linux_fixup+0x33c >>> >> >> >>> kern_execve(c5c24580,e7481c3c,0,8112710,8116cd8,...) at kern_execve+0x7d6 >>> >> >> >>> linux_execve(c5c24580,e7481cec,c,c,c,...) at linux_execve+0xa7 >>> >> >> >>> syscall(e7481d28) at syscall+0x372 >>> >> >> >>> Xint0x80_syscall() at Xint0x80_syscall+0x21 >>> >> >> >>> --- syscall (11, Linux ELF, linux_execve), eip = 0x281e0d4a, esp = 0xbfbfd644, ebp = 0xbfbfd7e8 --- >>> >> >> >>> >>> >> >> >>> #0 doadump () at pcpu.h:244 >>> >> >> >>> #1 0xc05de609 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:441 >>> >> >> >>> #2 0xc05de84f in panic (fmt=Variable "fmt" is not available. >>> >> >> >>> ) at /usr/src/sys/kern/kern_shutdown.c:614 >>> >> >> >>> #3 0xc08b22c3 in trap_fatal (frame=0xe7481a2c, eva=3217022972) at /usr/src/sys/i386/i386/trap.c:981 >>> >> >> >>> #4 0xc08b2357 in trap_pfault (frame=0xe7481a2c, usermode=0, eva=3217022972) at /usr/src/sys/i386/i386/trap.c:843 >>> >> >> >>> #5 0xc08b3133 in trap (frame=0xe7481a2c) at /usr/src/sys/i386/i386/trap.c:562 >>> >> >> >>> #6 0xc089bedc in calltrap () at /usr/src/sys/i386/i386/exception.s:168 >>> >> >> >>> #7 0xc50b396c in elf_linux_fixup (stack_base=0xe7481c0c, imgp=0xe7481b98) at /usr/src/sys/modules/linux/../../i386/linux/linux_sysvec.c:288 >>> >> >> >>> #8 0xc05ac636 in kern_execve (td=0xc5c24580, args=0xe7481c3c, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:551 >>> >> >> >>> #9 0xc50ab387 in linux_execve (td=0xc5c24580, args=0xe7481cec) at /usr/src/sys/modules/linux/../../i386/linux/linux_machdep.c:143 >>> >> >> >>> #10 0xc08b2902 in syscall (frame=0xe7481d28) at subr_syscall.c:114 >>> >> >> >>> #11 0xc089bf41 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:266 >>> >> >> >>> #12 0x00000033 in ?? () >>> >> >> >>> >>> >> >> >> I am not sure if this is the real cause of your panic, but the line from >>> >> >> >> the backtrace indeed has a bug. Please try the change below. >>> >> >> >> >>> >> >> >> diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linux_sysvec.c >>> >> >> >> index 7634138..d4e23e1 100644 >>> >> >> >> --- a/sys/i386/linux/linux_sysvec.c >>> >> >> >> +++ b/sys/i386/linux/linux_sysvec.c >>> >> >> >> @@ -227,11 +227,11 @@ linux_fixup(register_t **stack_base, struct image_params *imgp) >>> >> >> >> argv = *stack_base; >>> >> >> >> envp = *stack_base + (imgp->args->argc + 1); >>> >> >> >> (*stack_base)--; >>> >> >> >> - **stack_base = (intptr_t)(void *)envp; >>> >> >> >> + suword(*stack_base, (intptr_t)(void *)envp); >>> >> >> >> (*stack_base)--; >>> >> >> >> - **stack_base = (intptr_t)(void *)argv; >>> >> >> >> + suword(*stack_base, (intptr_t)(void *)argv); >>> >> >> >> (*stack_base)--; >>> >> >> >> - **stack_base = imgp->args->argc; >>> >> >> >> + suword(*stack_base, imgp->args->argc); >>> >> >> >> return (0); >>> >> >> >> } >>> >> >> >> >>> >> >> >> @@ -286,7 +286,7 @@ elf_linux_fixup(register_t **stack_base, struct image_params *imgp) >>> >> >> >> imgp->auxargs = NULL; >>> >> >> >> >>> >> >> >> (*stack_base)--; >>> >> >> >> - **stack_base = (register_t)imgp->args->argc; >>> >> >> >> + suword(*stack_base, (register_t)imgp->args->argc); >>> >> >> >> return (0); >>> >> >> >> } >>> >> >> >> >>> >> >> > >>> >> >> > Thanks for the response! I will try the patch, but that file has not >>> >> >> > been touched since June 2011. I was suspecting the changes in r231146 >>> >> >> > and r231148. If there is no change with your patch I will roll back >>> >> >> > those to see what happens. >>> >> > This is very unlikely. fadvise() has nothing to do with image activators. >>> >> > >>> >> >> >>> >> >> No panics so far. That patch does indeed seem to solve the problem! I >>> >> >> also verified with going back to the old kernel, which again >>> >> >> consistently paniced. >>> >> > I will commit the change in minutes. Kernel must not access usermode >>> >> > addresses directly. >>> >> > >>> >> > But, does the application that used to panic the system, behave properly ? >>> >> >>> >> Yes, it (acroread8) does behave properly with the patch. Have not >>> >> tested extensively, however. >>> >> >>> >> >> Thanks very much for good work! >>> >> >> >>> >> >> I'm a but puzzled though, because that bug must have been there for >>> >> >> quite some time without triggering the panic. >>> >> > The panic with unpatched kernel looks puzzling. Do you have some >>> >> > non-default stack limit ? Can you look at the resource limit values >>> >> > for the process initiated the panic ? >>> >> >>> >> Not that I'm aware of. Unless the acroread launch script does this. I >>> >> don't know how to check this for a running process, but "limits|grep >>> >> stack" in a regular shell gives me: >>> >> >>> >> stacksize 65536 kB >>> >> >>> >> Or, do you mean that I can dig that out of the crash dump? If so, I'll >>> >> need some help with how to. >>> > >>> > From the kgdb, frame 8, print the content of td->td_proc->p_limit. >>> >>> Is this it? >>> >>> (kgdb) frame 8 >>> #8 0xc05ac636 in kern_execve (td=0xc5dc3000, args=0xe7535c3c, mac_p=0x0) >>> at /usr/src/sys/kern/kern_exec.c:551 >>> 551 (*p->p_sysent->sv_fixup)(&stack_base, imgp); >>> (kgdb) print td->td_proc->p_limit >>> $1 = (struct plimit *) 0xc5490700 >>> (kgdb) print *td->td_proc->p_limit >>> $2 = {pl_rlimit = {{rlim_cur = 9223372036854775807, >>> rlim_max = 9223372036854775807}, {rlim_cur = 9223372036854775807, >>> rlim_max = 9223372036854775807}, {rlim_cur = 536870912, >>> rlim_max = 536870912}, {rlim_cur = 67108864, rlim_max = 67108864}, { >>> rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { >>> rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { >>> rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { >>> rlim_cur = 5547, rlim_max = 5547}, {rlim_cur = 11095, rlim_max = 11095}, >>> {rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { >>> rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { >>> rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}, { >>> rlim_cur = 9223372036854775807, rlim_max = 9223372036854775807}}, >>> pl_refcnt = 51} >> Yes, but the stack size is the normal 64MB. >> >> Did other linux binaries worked before the patch ? E.g., did the bash >> started normally ? > > Hmm, I see now that the crash dump actually says that it is bash that is > running, not acroread. The acroread startup script invokes a linux bash > to launch the acroread binary, so I guess acroread was actually never > started. > > I should also say that I was running KDE. I can test invoking linux > bash and some other linux utilities without any Xorg+KDE to see what > happens. I however don't have time today for this. I tried to reproduce today with other linux programs, but strangely enough I can't reproduce it at all, not even with acroread. I'll run memtest to see whether I have any ram problems. Bengt From owner-freebsd-emulation@FreeBSD.ORG Tue Feb 28 18:42:35 2012 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93D25106564A for ; Tue, 28 Feb 2012 18:42:35 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4CF4A8FC0C for ; Tue, 28 Feb 2012 18:42:34 +0000 (UTC) Received: by ggnk4 with SMTP id k4so1907657ggn.13 for ; Tue, 28 Feb 2012 10:42:34 -0800 (PST) Received-SPF: pass (google.com: domain of artemb@gmail.com designates 10.236.181.193 as permitted sender) client-ip=10.236.181.193; Authentication-Results: mr.google.com; spf=pass (google.com: domain of artemb@gmail.com designates 10.236.181.193 as permitted sender) smtp.mail=artemb@gmail.com; dkim=pass header.i=artemb@gmail.com Received: from mr.google.com ([10.236.181.193]) by 10.236.181.193 with SMTP id l41mr30049609yhm.38.1330454554471 (num_hops = 1); Tue, 28 Feb 2012 10:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=boUOYA5f/X03+n/y3DZm5rXTd6rPVLbqmr7kOnEqowE=; b=bNBtK6YpWKKNNXxP4+bomkVxVTc2DTqEqg/k2l7Wm1VM2cyh+mj3n6V0igCMEk/EJD rPvKPj4SRRux6nyvQgsJ8b4eCokw+DaQ8NSxnwGHSkhBo9UZyszNX4a/kR9DEdPx/Dxo bZ24ZMrIvnebfiYNt3DO0lS1uYEsnkAKBF5tQ= MIME-Version: 1.0 Received: by 10.236.181.193 with SMTP id l41mr22662970yhm.38.1330453236364; Tue, 28 Feb 2012 10:20:36 -0800 (PST) Sender: artemb@gmail.com Received: by 10.146.159.40 with HTTP; Tue, 28 Feb 2012 10:20:36 -0800 (PST) In-Reply-To: <4F4CA10E.3070508@rawbw.com> References: <4F4CA10E.3070508@rawbw.com> Date: Tue, 28 Feb 2012 10:20:36 -0800 X-Google-Sender-Auth: c9EHz9GSu67y2w-1ILs2PFv1ym8 Message-ID: From: Artem Belevich To: Yuri Content-Type: text/plain; charset=ISO-8859-1 Cc: emulation@freebsd.org Subject: Re: Why ldd(1) launches linux apps? 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, 28 Feb 2012 18:42:35 -0000 lss just sets TRACE_LOADED_OBJECTS environment variable and then execs the binary. FreeBSD's dynamic linker then checks for that variable and, if set, just prints out loaded objects and then exists. When you run ldd on a linux binary, it's *Linux* dynamic linker that gets launched and it may have different way of triggering the trace. That said, ldd seems to work fine on linux binaries on FreeBSD-7, but does indeed launch linux binary in 8-STABLE, so something has changed. If you do 'env LD_TRACE_LOADED_OBJECTS=1 /compat/linux/bin/cp' on 8-STABLE it still works fine. --Artem On Tue, Feb 28, 2012 at 1:40 AM, Yuri wrote: > I noticed the strange thing. > ldd(1) launches all linux apps I tried (skype, acroread9). And it doesn't > launch BSD apps. > > Is this a knows issue? > > Yuri > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.org" From owner-freebsd-emulation@FreeBSD.ORG Wed Feb 29 05:42:58 2012 Return-Path: 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 43045106566B; Wed, 29 Feb 2012 05:42:58 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id A05748FC08; Wed, 29 Feb 2012 05:42:57 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so2691596wib.13 for ; Tue, 28 Feb 2012 21:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=UGa8cjL2Im3Bh2DUnllmrouyBdLFrqMtaML9DzDrGAM=; b=myth6M96feSk/KcQyI2cq23hXM1jTBb+0WlDRHS3LZcHOapiFFkKKDH7a+XjFWiXhK Yx+RdcDq/U4B62JK+bOk1F2ZUoxJnOMmkvUpDFSnh+y2lQdwDZ4/svLZSdHryMtAgFZo ceCmGXqwIkPxQqzTbANwexpJD89N9vEqheS5k= Received: by 10.180.14.37 with SMTP id m5mr26736897wic.19.1330494176684; Tue, 28 Feb 2012 21:42:56 -0800 (PST) Received: from dragon.dg (41-132-92-120.dsl.mweb.co.za. [41.132.92.120]) by mx.google.com with ESMTPS id d8sm19285281wia.11.2012.02.28.21.42.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Feb 2012 21:42:55 -0800 (PST) From: David Naylor To: freebsd-questions@freebsd.org, freebsd-emulation@freebsd.org Date: Wed, 29 Feb 2012 07:42:46 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.1; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1903142.K7G3jya4tf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201202290742.50090.naylor.b.david@gmail.com> Cc: Subject: Wine-fbsd64 updated to 1.4.rc5 (32bit Wine for 64bit FreeBSD) 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: Wed, 29 Feb 2012 05:42:58 -0000 --nextPart1903142.K7G3jya4tf Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Packages [1] for wine-fbsd64-1.4.rc5 have been uploaded to mediafire [2]. There are many reports that wine does not work with a clang compiled world (help in fixing this problem is appreciated as it affects quite a few users). The patch [3] for nVidia users is now included in the package and is run on installation (if the relevant files are accessible). Please read the installation messages for further information. Regards, David [1] MD5 (freebsd8/wine-fbsd64-1.4.rc5,1.tbz) = 53c37ef9fbd0f12f6c456efac942a575 MD5 (freebsd9/wine-fbsd64-1.4.rc5,1.txz) = 4f653f5d8e29fd5e7811dec2f81469a8 [2] http://www.mediafire.com/wine_fbsd64 [3] The patch is located at /usr/local/share/wine/patch-nvidia.sh --nextPart1903142.K7G3jya4tf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEABECAAYFAk9NutoACgkQUaaFgP9pFrKl7gCdEhZKNhnt8mH2F9qkiANELHuj 85MAoIOu/sKPutjyBoYmJ+fEEOOWprzn =crPI -----END PGP SIGNATURE----- --nextPart1903142.K7G3jya4tf-- From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 1 16:30:08 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8823106566B for ; Thu, 1 Mar 2012 16:30:08 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7BCFE8FC14 for ; Thu, 1 Mar 2012 16:30:08 +0000 (UTC) Received: from [82.113.98.149] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1S381F-0004uC-LB; Thu, 01 Mar 2012 16:34:14 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q21FYBVD002527; Thu, 1 Mar 2012 16:34:11 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q21FYAp2002526; Thu, 1 Mar 2012 16:34:10 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Thu, 1 Mar 2012 16:34:10 +0100 From: Matthias Apitz To: freebsd-emulation@freebsd.org Message-ID: <20120301153409.GA2478@tiny> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.98.149 Cc: freebsd-current@freebsd.org Subject: skype-2.1.0.81,1 && problem in child proc X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 16:30:08 -0000 Hello, I'm using skype-2.1.0.81,1 in 10-CURRENT r226986, which works fine for chat and video calls; I encounter the following small problem: when a chat contains a URL one can open that URL with a browser; it seems that skype is launching a shell script /usr/local/bin/xdg-open which in turn tries to figure out if the desktop is Gnome or KDE and which browser to use; it simple does not start any browser for me; while digging into this (inserting printf's to a log file) I see, that the script wants to launch kfmclient exec http://www.hallo-verlag.de/... with the correct URL from the chat dialog in skype but this gives an error to stderr: Cannot open "/usr/lib/libv4l/v4l2convert.so" the shared lib exists in /compat/linux/usr/lib/libv4l/v4l2convert.so and in /usr/local/lib/libv4l/v4l2convert.so $ ls -l /usr/local/lib/libv4l/v4l2convert.so /compat/linux/usr/lib/libv4l/v4l2convert.so -rwxr-xr-x 1 root wheel 4788 14 nov 12:52 /compat/linux/usr/lib/libv4l/v4l2convert.so -rwxr-xr-x 1 root wheel 5341 14 nov 07:49 /usr/local/lib/libv4l/v4l2convert.so What is the matter with this and was has 'kfmclient' todo with v4l2convert.so shared objects? Thanks matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 From owner-freebsd-emulation@FreeBSD.ORG Thu Mar 1 21:28:51 2012 Return-Path: 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 6CAFD106566B; Thu, 1 Mar 2012 21:28:51 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 2ADC28FC08; Thu, 1 Mar 2012 21:28:51 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 584C81E00078; Thu, 1 Mar 2012 22:13:37 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.4) with ESMTP id q21LDEhe009575; Thu, 1 Mar 2012 22:13:14 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id q21LDEjW009574; Thu, 1 Mar 2012 22:13:14 +0100 (CET) (envelope-from nox) Date: Thu, 1 Mar 2012 22:13:14 +0100 (CET) From: Juergen Lock Message-Id: <201203012113.q21LDEjW009574@triton8.kn-bremen.de> To: guru@unixarea.de X-Newsgroups: local.list.freebsd.current In-Reply-To: <20120301153409.GA2478@tiny> Organization: Cc: gnome@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: skype-2.1.0.81,1 && problem in child proc 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: Thu, 01 Mar 2012 21:28:51 -0000 In article <20120301153409.GA2478@tiny> you write: > >Hello, > >I'm using skype-2.1.0.81,1 in 10-CURRENT r226986, which works fine for >chat and video calls; > >I encounter the following small problem: when a chat contains a URL one >can open that URL with a browser; it seems that skype is launching a >shell script /usr/local/bin/xdg-open which in turn tries to figure out >if the desktop is Gnome or KDE and which browser to use; it simple does >not start any browser for me; while digging into this (inserting >printf's to a log file) I see, that the script wants to launch > >kfmclient exec http://www.hallo-verlag.de/... > >with the correct URL from the chat dialog in skype but this gives an >error to stderr: > >Cannot open "/usr/lib/libv4l/v4l2convert.so" > >the shared lib exists in /compat/linux/usr/lib/libv4l/v4l2convert.so >and in /usr/local/lib/libv4l/v4l2convert.so > >$ ls -l /usr/local/lib/libv4l/v4l2convert.so >/compat/linux/usr/lib/libv4l/v4l2convert.so >-rwxr-xr-x 1 root wheel 4788 14 nov 12:52 >/compat/linux/usr/lib/libv4l/v4l2convert.so >-rwxr-xr-x 1 root wheel 5341 14 nov 07:49 >/usr/local/lib/libv4l/v4l2convert.so > >What is the matter with this and was has 'kfmclient' todo with >v4l2convert.so shared objects? I haven't really looked into this in detail but my guess is this is the Linux v4l2convert.so that is LD_PRELOAD'ed into skype for the benefit of cameras not able to provida yuv video. So I guess we'd need to prepend a wrapper for xdg-open to PATH that resets LD_PRELOAD before executing the real /usr/local/bin/xdg-open . (And btw I had to do something similar for google earth which sets LD_LIBRARY_PATH, see /usr/ports/astro/google-earth/files/browserwrapper and /usr/ports/astro/google-earth/files/patch-bin-googleearth .) Hm or should the xdg-utils port be patched to just unset LD_PRELOAD uncondtionally? I'll Cc gnome@ which is listed as maintainer for that port... Cheers, Juergen From owner-freebsd-emulation@FreeBSD.ORG Fri Mar 2 04:53:41 2012 Return-Path: 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 222DA106566B for ; Fri, 2 Mar 2012 04:53:41 +0000 (UTC) (envelope-from andy@neu.net) Received: from mail.neu.net (unknown [IPv6:2607:fc50:0:d300:216:3eff:fe54:f1c6]) by mx1.freebsd.org (Postfix) with ESMTP id D69B68FC0C for ; Fri, 2 Mar 2012 04:53:40 +0000 (UTC) Received: from neu.net (neu.net [199.48.129.194]) by mail.neu.net (8.14.5/8.14.5) with ESMTP id q224rWJD065729 for ; Thu, 1 Mar 2012 23:53:38 -0500 (EST) (envelope-from andy@neu.net) Date: Thu, 1 Mar 2012 23:53:32 -0500 (EST) From: AN To: freebsd-emulation@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-0.0 required=5.0 tests=T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.neu.net Cc: Subject: vbox install fails 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: Fri, 02 Mar 2012 04:53:41 -0000 uname -a FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r232369: Thu Mar 1 20:26:30 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Trying to install vbox 4.1.8 and 4.0.6Legacy, I get the following error: kBuild: Compiling tstVMStructRC - /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/src/VBox/VMM/testcase/tstVMStructRC.cpp In file included from /usr/include/sys/types.h:63, from /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/include/iprt/types.h:85, from /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/include/VBox/types.h:30, from /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/src/VBox/VMM/testcase/tstVMStructRC.cpp:33: /usr/include/sys/_stdint.h:74: error: conflicting declaration 'typedef __intptr_t intptr_t' /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/include/iprt/stdint.h:162: error: 'intptr_t' has a previous declaration as 'typedef long int intptr_t' /usr/include/sys/_stdint.h:78: error: conflicting declaration 'typedef __uintptr_t uintptr_t' /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/include/iprt/stdint.h:165: error: 'uintptr_t' has a previous declaration as 'typedef long unsigned int uintptr_t' kBuild: Generating tstVMStructSize - /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/out/freebsd.amd64/release/obj/VMM/tstAsmStructsAsm.mac /usr/local/bin/kmk_sed -f /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/src/VBox/VMM/testcase/tstAsmStructsAsm-lst.sed --output /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/out/freebsd.amd64/release/obj/VMM/tstAsmStructsAsm.mac /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/out/freebsd.amd64/release/obj/VMM/tstAsmStructsAsm.mac.lst kBuild: Compiling tstGlobalConfig - /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/src/VBox/VMM/testcase/tstGlobalConfig.cpp kmk: *** [/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/out/freebsd.amd64/release/obj/tstVMStructRC/tstVMStructRC.o] Error 1 The failing command: @c++ -m32 -c -O2 -g -pipe -pedantic -Wshadow -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-trigraphs -fdiagnostics-show-option -Wno-long-long -Wno-variadic-macros -fno-exceptions -O2 -mtune=generic -fno-omit-frame-pointer -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fno-strict-aliasing -fno-stack-protector -fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN -DRT_USE_VISIBILITY_DEFAULT -fvisibility-inlines-hidden -fno-rtti -O0 -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/src/VBox/VMM/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/src/VBox/VMM/PATM -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/out/freebsd.amd64/release -DVBOX -DVBOX_WITH_DEBUGGER -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_HARDENING -DRTPATH_APP_PRIVATE=\"/usr/local/share/virtualbox-ose\" -DRTPATH_APP_PRIVATE_ARCH=\"/usr/local/lib/virtualbox\" -DRTPATH_SHARED_LIBS=\"/usr/local/lib/virtualbox\" -DRTPATH_APP_DOCS=\"/usr/local/share/doc/virtualbox-ose\" -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_X86 -D__X86__ -DIN_RC -DHC_ARCH_BITS=64 -DGC_ARCH_BITS=64 -DIN_VMM_RC -DIN_DIS -DIN_RT_RC -DVBOX_WITH_RAW_MODE -DIPRT_DONT_USE_SYSTEM_STDINT_H -Wp,-MD,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/out/freebsd.amd64/release/obj/tstVMStructRC/tstVMStructRC.o.dep -Wp,-MT,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/out/freebsd.amd64/release/obj/tstVMStructRC/tstVMStructRC.o -Wp,-MP -o /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/out/freebsd.amd64/release/obj/tstVMStructRC/tstVMStructRC.o /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.1.8_OSE/src/VBox/VMM/testcase/tstVMStructRC.cpp kmk: *** Waiting for unfinished jobs.... kmk: *** Exiting with status 2 *** [do-build] Error code 2 Stop in /usr/ports/emulators/virtualbox-ose. *** [install] Error code 1 Stop in /usr/ports/emulators/virtualbox-ose. [root@FBSD10 /usr/ports/emulators/virtualbox-ose]# Any help fixing this would be appreciated, tia. From owner-freebsd-emulation@FreeBSD.ORG Fri Mar 2 07:51:57 2012 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D436106564A; Fri, 2 Mar 2012 07:51:57 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id DC2878FC23; Fri, 2 Mar 2012 07:51:56 +0000 (UTC) Received: from [82.113.119.193] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1S3NHO-0000oj-Go; Fri, 02 Mar 2012 08:51:54 +0100 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id q227ptkh001360; Fri, 2 Mar 2012 08:51:55 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id q227psuH001359; Fri, 2 Mar 2012 08:51:54 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Fri, 2 Mar 2012 08:51:54 +0100 From: Matthias Apitz To: Juergen Lock Message-ID: <20120302075153.GA1349@tiny> References: <20120301153409.GA2478@tiny> <201203012113.q21LDEjW009574@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201203012113.q21LDEjW009574@triton8.kn-bremen.de> X-Operating-System: FreeBSD 10.0-CURRENT r226986 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.119.193 Cc: gnome@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: skype-2.1.0.81,1 && problem in child proc X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 07:51:57 -0000 El día Thursday, March 01, 2012 a las 10:13:14PM +0100, Juergen Lock escribió: > I haven't really looked into this in detail but my guess is this is > the Linux v4l2convert.so that is LD_PRELOAD'ed into skype for the > benefit of cameras not able to provida yuv video. So I guess we'd > need to prepend a wrapper for xdg-open to PATH that resets LD_PRELOAD > before executing the real /usr/local/bin/xdg-open . (And btw I had > to do something similar for google earth which sets LD_LIBRARY_PATH, > see > > /usr/ports/astro/google-earth/files/browserwrapper > > and > > /usr/ports/astro/google-earth/files/patch-bin-googleearth > > .) > > Hm or should the xdg-utils port be patched to just unset LD_PRELOAD > uncondtionally? I'll Cc gnome@ which is listed as maintainer for > that port... I've set now a hardcoded 'unset LD_PRELOAD' in /usr/local/bin/xdg-open and on click on the URL konqueror comes up fine with the URL; thanks for the hint; matthias -- Matthias Apitz e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5