From owner-freebsd-emulation@FreeBSD.ORG Fri Feb 17 17:26:37 2012 Return-Path: Delivered-To: emulation@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 2A670106566B; Fri, 17 Feb 2012 17:26:37 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Andrey Chernov Date: Fri, 17 Feb 2012 12:26:27 -0500 User-Agent: KMail/1.6.2 References: <20120215164722.GA1693@vniz.net> <20120216203108.GA19525@vniz.net> <20120216212611.GA20146@vniz.net> In-Reply-To: <20120216212611.GA20146@vniz.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202171226.29752.jkim@FreeBSD.org> Cc: "ports@FreeBSD.org" , "emulation@FreeBSD.org" , Volodymyr Kostyrko , "jkim@FreeBSD.org" Subject: Re: nspluginwrapper (was Re: linux-f10-flashplugin11 not works for 9-stable (Linuxulator?)) 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, 17 Feb 2012 17:26:37 -0000 On Thursday 16 February 2012 04:26 pm, Andrey Chernov wrote: > It seems part of the bug is already noticed by maintainer (Jung-uk > Kim) but nothing is done to fix it: > http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/06 >4067.html BTW, the bug is in native FreeBSD code (rpc.c), not in > linux code. > > Jung-uk, could you fix/hack it somehow, please? Linuxulator does not support "abstract namespace" yet and it is hard problem. However, nspluginwrapper does not use abstract namespace when it is built for non-Linux platform, i.e., "--enable-generic" configure option unsets "USE_ANONYMOUS_SOCKETS" for both Linux and FreeBSD. OTH, FreeBSD-SA-11:05.unix broke Linuxulator but it was quickly patched by cperciva and refined by me *before* 9.0-RELEASE. Jung-uk Kim > On Fri, Feb 17, 2012 at 12:31:08AM +0400, Andrey Chernov wrote: > > On Thu, Feb 16, 2012 at 11:47:05AM +0200, Volodymyr Kostyrko wrote: > > > Andrey Chernov wrote: > > > > Having 9-stable and ports from Feb 14, all builded from > > > > sources, I get this commonly looking error attempting to view > > > > flash in FF 10.0.1: > > > > > > > > *** NSPlugin Wrapper *** ERROR: failed to initialize > > > > plugin-side RPC client connection > > > > NOTE: child process received `Goodbye', closing down > > > > > > > > Looking into ktrace I found error reason: > > > > > > > > 82037 plugin-container CALL connect(0x16,0x2c04f9d4,0x42) > > > > 82037 plugin-container STRU struct sockaddr { AF_LOCAL, > > > > invalid } 82037 plugin-container NAMI > > > > "/tmp/_org_wrapper_NSPlugins_libflashplayer.so_82037-2_180428 > > > >9383" 82037 plugin-container RET connect -1 errno 2 No such > > > > file or directory > > > > > > > > (repeated several times). > > > > > > > > This "invalid" in sockaddr looks familiar as for some time > > > > ago added sockaddr length checks our kernel, but as bz@ says > > > > this should be already fixed. > > > > > > > > Does anybody runs flash successfly on 9-stable? If yes, where > > > > else the problem can be? > > > > > > Am running flash successfully on 9-stable (daily rebuild). > > > Works for me under chromium/seamonkey. > > > > > > Just filed a patch for the latest flash version... Works for me > > > also. > > > > Do you have recently-builded nspluginwrapper from sources? It > > seems the bug is there, since even that does not work: > > > > # nspluginplayer --verbose type=application/x-shockwave-flash > > src=some.swf > > *** NSPlugin Player *** swf application/x-shockwave-flash > > Shockwave Flash *** NSPlugin Player *** spl > > application/futuresplash > > FutureSplash Player *** NSPlugin Wrapper *** ERROR: failed to > > initialize plugin-side RPC client connection *** NSPlugin Player > > *** ERROR: could not execute: NPERR_MODULE_LOAD_FAILED_ERROR > > > > And I see very suspicious socket_addr_len size related code > > (which recent SA-fixes address) in rpc.c there: > > > > connection->socket_addr_len = > > _rpc_socket_path(&connection->socket_path, ident); > > memcpy(&connection->socket_addr.sun_path[0], > > connection->socket_path, connection->socket_addr_len); > > connection->socket_addr_len += offsetof(struct sockaddr_un, > > sun_path); /* though POSIX says size of the actual sockaddr > > structure */ #ifdef HAVE_SOCKADDR_UN_SUN_LEN > > connection->socket_addr.sun_len = connection->socket_addr_len; > > #endif