From owner-freebsd-chromium@freebsd.org Sun Jul 3 00:23:20 2016 Return-Path: Delivered-To: freebsd-chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A7FAB81728 for ; Sun, 3 Jul 2016 00:23:20 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4A129B3 for ; Sun, 3 Jul 2016 00:23:20 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7A6A3B81726; Sun, 3 Jul 2016 00:23:20 +0000 (UTC) Delivered-To: chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A084B81725 for ; Sun, 3 Jul 2016 00:23:20 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55A5929B2 for ; Sun, 3 Jul 2016 00:23:19 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1467505398288244.40473045015187; Sat, 2 Jul 2016 17:23:18 -0700 (PDT) Date: Sat, 02 Jul 2016 17:23:18 -0700 From: Matthew Macy To: "chromium" Message-ID: <155ae2351dc.d435e15355364.689950361019774764@nextbsd.org> Subject: chrome spends all its time calling open MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 00:23:20 -0000 While looking at other issues I tried running truss on chrome at startup and I discovered a certain rather dysfunctional behavior: lanecrash# grep "close(" chrome.log | wc 1317903 7905445 68502169 planecrash# wc chrome.log 1466068 8798135 78854285 chrome.log It repeatedly calls close on 1 up to ~128000. System calls aren't expensive per se, but if almost 95% of your system calls are close you're doing something quite wrong. -M From owner-freebsd-chromium@freebsd.org Sun Jul 3 00:24:14 2016 Return-Path: Delivered-To: freebsd-chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E10AB817A8 for ; Sun, 3 Jul 2016 00:24:14 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9012A20 for ; Sun, 3 Jul 2016 00:24:14 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7CFA8B817A7; Sun, 3 Jul 2016 00:24:14 +0000 (UTC) Delivered-To: chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CA48B817A6 for ; Sun, 3 Jul 2016 00:24:14 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 707DE2A1F for ; Sun, 3 Jul 2016 00:24:14 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1467505452803193.00710994835595; Sat, 2 Jul 2016 17:24:12 -0700 (PDT) Date: Sat, 02 Jul 2016 17:24:12 -0700 From: Matthew Macy To: "chromium" Message-ID: <155ae2426da.ecd708a055370.6844710089510046027@nextbsd.org> In-Reply-To: <155ae2351dc.d435e15355364.689950361019774764@nextbsd.org> References: <155ae2351dc.d435e15355364.689950361019774764@nextbsd.org> Subject: chrome spends all its time calling close Re: chrome spends all its time calling open MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 00:24:14 -0000 Subject line was wrong. ---- On Sat, 02 Jul 2016 17:23:18 -0700 Matthew Macy wrote ---- > > While looking at other issues I tried running truss on chrome at startup and I discovered a certain rather dysfunctional behavior: > > > lanecrash# grep "close(" chrome.log | wc > 1317903 7905445 68502169 > planecrash# wc chrome.log > 1466068 8798135 78854285 chrome.log > > It repeatedly calls close on 1 up to ~128000. System calls aren't expensive per se, but if almost 95% of your system calls are close you're doing something quite wrong. > > -M From owner-freebsd-chromium@freebsd.org Wed Jul 6 14:13:38 2016 Return-Path: Delivered-To: freebsd-chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12BFCB75E4C for ; Wed, 6 Jul 2016 14:13:38 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id F2B9E12E4 for ; Wed, 6 Jul 2016 14:13:37 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: by mailman.ysv.freebsd.org (Postfix) id F21C0B75E4B; Wed, 6 Jul 2016 14:13:37 +0000 (UTC) Delivered-To: chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1C04B75E4A for ; Wed, 6 Jul 2016 14:13:37 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: from mail.kapsi.fi (mx1.kapsi.fi [IPv6:2001:1bc8:1004::1:25]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6F9A12E3 for ; Wed, 6 Jul 2016 14:13:37 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: from kirsikka.kapsi.fi ([217.30.184.185] helo=roundcube.kapsi.fi) by mail.kapsi.fi with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1bKna1-0002kH-OQ; Wed, 06 Jul 2016 17:13:33 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 06 Jul 2016 17:13:33 +0300 From: Arto Pekkanen To: Matthew Macy Cc: chromium Subject: Re: chrome spends all its time calling close Re: chrome spends all its time calling open In-Reply-To: <155ae2426da.ecd708a055370.6844710089510046027@nextbsd.org> References: <155ae2351dc.d435e15355364.689950361019774764@nextbsd.org> <155ae2426da.ecd708a055370.6844710089510046027@nextbsd.org> Message-ID: <23d62c1559ad130b7ae7f812ad7f0a0c@kapsi.fi> X-Sender: isoa@kapsi.fi User-Agent: RoundCube Webmail/0.9.4 X-SA-Exim-Connect-IP: 217.30.184.185 X-SA-Exim-Mail-From: isoa@kapsi.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 14:13:38 -0000 Matthew Macy kirjoitti 03.07.2016 03:24: > Subject line was wrong. > > > ---- On Sat, 02 Jul 2016 17:23:18 -0700 Matthew Macy > wrote ---- > > > > While looking at other issues I tried running truss on chrome at > startup and I discovered a certain rather dysfunctional behavior: > > > > > > lanecrash# grep "close(" chrome.log | wc > > 1317903 7905445 68502169 > > planecrash# wc chrome.log > > 1466068 8798135 78854285 chrome.log > > > > It repeatedly calls close on 1 up to ~128000. System calls aren't > expensive per se, but if almost 95% of your system calls are close > you're doing something quite wrong. > > > > -M The FreeBSD port of Chromium does too many things wrong. It cannot even properly manage memory, because it's render processes frequently crash with SIGSEGV somewhere in the standard C++ library. Also the page www.kickstarter.com crashes everytime with Chromium specific MAPERR -error, which is yet again another instance implication that the memory management code does not work with FreeBSD. All these problems started a few years ago, cannot remember when. There are two PRs about these hard and soft crashes, but nobody has done anything to fix them. See here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204454 <-- frequent tab crashes (soft crash) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207298 <-- kickstarter.com crashes (hard crash) The maintainers just keep updating the www/chromium port and hope that some newer version would make these issues go away, but I think the problem is deeper than that. Probably something to do with the behavioural differences of syscalls between FreeBSD and Linux. Such problems will not go away over version upgrades. I've done some of debugging myself, and figured out that the the SIGSEGV is triggered somewhere in libstdc++. But I cannot fix these issues because I am not familiar with the Chromium codebase, Linux vs FreeBSD syscall differences or even stdc++ specific issues. Also, Firefox doesn't work properly, it starts using 100% CPU after few hours of use. Again, no solutions, not enough PRs, nobody fixing the problem. There was some issue with the oss sound backend, but having it fixed still does not rectify the overall slowdown issue. We cannot even figure out where Firefox uses all the CPU because the FreeBSD version of Firefox does not support profiling at all. The compile time option PROFILE does absolutely nothing. Ergo, there are no stable, modern full featured browsers for FreeBSD users. Only unstable imports from Linux, pieced together with a bundle of patches. If we are to get a decent browser for FreeBSD, one of two things HAVE to happen: 1) a few FreeBSD developers become involved in Firefox and Chromium development, actually fixing these problems with communication and collaboration upstream or 2) somebody needs to create a modern, full featured browser specifically for FreeBSD Not sure if any of these gonna happen any time soon. -- Arto Pekkanen From owner-freebsd-chromium@freebsd.org Wed Jul 6 18:50:35 2016 Return-Path: Delivered-To: freebsd-chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69F9AB75E35 for ; Wed, 6 Jul 2016 18:50:35 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 579941E02 for ; Wed, 6 Jul 2016 18:50:35 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 51959B75E32; Wed, 6 Jul 2016 18:50:35 +0000 (UTC) Delivered-To: chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 513C9B75E31 for ; Wed, 6 Jul 2016 18:50:35 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 354DE1E00 for ; Wed, 6 Jul 2016 18:50:34 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1467831022837904.013411633383; Wed, 6 Jul 2016 11:50:22 -0700 (PDT) Date: Wed, 06 Jul 2016 11:50:22 -0700 From: Matthew Macy To: "Arto Pekkanen" Cc: "chromium" Message-ID: <155c18bf4bc.df8f34f148837.2668232318689911733@nextbsd.org> In-Reply-To: <23d62c1559ad130b7ae7f812ad7f0a0c@kapsi.fi> References: <155ae2351dc.d435e15355364.689950361019774764@nextbsd.org> <155ae2426da.ecd708a055370.6844710089510046027@nextbsd.org> <23d62c1559ad130b7ae7f812ad7f0a0c@kapsi.fi> Subject: Re: chrome spends all its time calling close Re: chrome spends all its time calling open MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 18:50:35 -0000 ---- On Wed, 06 Jul 2016 07:13:33 -0700 Arto Pekkanen wrote ---- > Matthew Macy kirjoitti 03.07.2016 03:24: > > Subject line was wrong. > > > > > > ---- On Sat, 02 Jul 2016 17:23:18 -0700 Matthew Macy > > wrote ---- > > > > > > While looking at other issues I tried running truss on chrome at > > startup and I discovered a certain rather dysfunctional behavior: > > > > > > > > > lanecrash# grep "close(" chrome.log | wc > > > 1317903 7905445 68502169 > > > planecrash# wc chrome.log > > > 1466068 8798135 78854285 chrome.log > > > > > > It repeatedly calls close on 1 up to ~128000. System calls aren't > > expensive per se, but if almost 95% of your system calls are close > > you're doing something quite wrong. > > > > > > -M > > The FreeBSD port of Chromium does too many things wrong. It cannot even > properly manage memory, because it's render processes frequently crash > with SIGSEGV somewhere in the standard C++ library. Also the page > www.kickstarter.com crashes everytime with Chromium specific MAPERR > -error, which is yet again another instance implication that the memory > management code does not work with FreeBSD. That's interesting. At least the particular problem that I raised can be fixed very easily. I encountered the same issue running apt chrooted in /compat/linux. If a process can't open /proc/self/fd it resorts to closing every possibly open file descriptor up to its rlimit. I fixed pseudofs to enable linprocfs to dynamically populate /proc//fd as a replacement for the soft link to /dev/fd (using fdescfs for this purpose is broken in a number of respects). I'm now hitting other issues running apt from xenial, but at least it no longer does this. One could easily add a sysctl node, e.g. proc.self.fd, for any of the procfs features that ported apps rely on. > All these problems started a few years ago, cannot remember when. > > There are two PRs about these hard and soft crashes, but nobody has done > anything to fix them. See here: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204454 <-- frequent > tab crashes (soft crash) > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207298 <-- > kickstarter.com crashes (hard crash) > > The maintainers just keep updating the www/chromium port and hope that > some newer version would make these issues go away, but I think the > problem is deeper than that. Probably something to do with the > behavioural differences of syscalls between FreeBSD and Linux. Such > problems will not go away over version upgrades. > > I've done some of debugging myself, and figured out that the the SIGSEGV > is triggered somewhere in libstdc++. But I cannot fix these issues > because I am not familiar with the Chromium codebase, Linux vs FreeBSD > syscall differences or even stdc++ specific issues. Unfortunate. Right now during non-networking time I'm most interested in getting Xenial's userland up and running chrooted under /compat/linux. This is initially to get Intel GPU Tools working so I can diagnose issues in i915 - but longer term so that we can run commercial applications like Steam and the NFLX browser client (widevine DRM is Linux only). After that I'll take a look at native Chromium issues as that falls under the auspices of my personal "enabling dogfooding" initiative. > Also, Firefox doesn't work properly, it starts using 100% CPU after few > hours of use. Again, no solutions, not enough PRs, nobody fixing the > problem. There was some issue with the oss sound backend, but having it > fixed still does not rectify the overall slowdown issue. We cannot even > figure out where Firefox uses all the CPU because the FreeBSD version of > Firefox does not support profiling at all. The compile time option > PROFILE does absolutely nothing. I actually have qualms with FF myself. With the new driver YouTube doesn't work and WebGL demos don't animate unless the user is moving the mouse. These are both symptoms that the browser isn't seeing vblank notifications. However, unlike chromium, FF does not directly access the /dev/dri/card0 device, so presumably it is talking to a helper application. I have no idea how this works. I need someone with a basic architectural understanding of FF to provide me with guidance. Barring that, FF will become a second class citizen and will need to be compiled with gpu acceleration disabled when DRM4.x displaces the DRM3.8 in HEAD. > Ergo, there are no stable, modern full featured browsers for FreeBSD > users. Only unstable imports from Linux, pieced together with a bundle > of patches. > > If we are to get a decent browser for FreeBSD, one of two things HAVE to > happen: > 1) a few FreeBSD developers become involved in Firefox and Chromium > development, actually fixing these problems with communication and > collaboration upstream > or > 2) somebody needs to create a modern, full featured browser specifically > for FreeBSD > > Not sure if any of these gonna happen any time soon. "Someone" (tm) needs to pick up the torch for #1. A browser developed specifically for FreeBSD seems impractical and doesn't make any sense to me. Next time someone asks "how can I contribute?" you have another possibility to add to the list. -M From owner-freebsd-chromium@freebsd.org Fri Jul 8 11:45:36 2016 Return-Path: Delivered-To: freebsd-chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31CA0B76846 for ; Fri, 8 Jul 2016 11:45:36 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1A1E11DDA for ; Fri, 8 Jul 2016 11:45:36 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: by mailman.ysv.freebsd.org (Postfix) id 15F98B76845; Fri, 8 Jul 2016 11:45:36 +0000 (UTC) Delivered-To: chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15A82B76844 for ; Fri, 8 Jul 2016 11:45:36 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: from mail.kapsi.fi (mx1.kapsi.fi [IPv6:2001:1bc8:1004::1:25]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CDA171DD9 for ; Fri, 8 Jul 2016 11:45:35 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: from karviainen.kapsi.fi ([217.30.184.182] helo=roundcube.kapsi.fi) by mail.kapsi.fi with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1bLUDr-0001IP-Mj; Fri, 08 Jul 2016 14:45:32 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 08 Jul 2016 14:45:31 +0300 From: Arto Pekkanen To: Matthew Macy Cc: chromium In-Reply-To: <155c18bf4bc.df8f34f148837.2668232318689911733@nextbsd.org> References: <155ae2351dc.d435e15355364.689950361019774764@nextbsd.org> <155ae2426da.ecd708a055370.6844710089510046027@nextbsd.org> <23d62c1559ad130b7ae7f812ad7f0a0c@kapsi.fi> <155c18bf4bc.df8f34f148837.2668232318689911733@nextbsd.org> Message-ID: <24ab4a7e5d956cb4f0198951e4fbc896@kapsi.fi> X-Sender: isoa@kapsi.fi User-Agent: RoundCube Webmail/0.9.4 X-SA-Exim-Connect-IP: 217.30.184.182 X-SA-Exim-Mail-From: isoa@kapsi.fi X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 Subject: Re: chrome spends all its time calling close Re: chrome spends all its time calling open X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mail.kapsi.fi) X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 11:45:36 -0000 Matthew Macy kirjoitti 06.07.2016 21:50: > > The FreeBSD port of Chromium does too many things wrong. It cannot > even > > properly manage memory, because it's render processes frequently > crash > > with SIGSEGV somewhere in the standard C++ library. Also the page > > www.kickstarter.com crashes everytime with Chromium specific MAPERR > > -error, which is yet again another instance implication that the > memory > > management code does not work with FreeBSD. > > That's interesting. At least the particular problem that I raised can > be fixed very easily. I encountered the same issue running apt > chrooted in /compat/linux. If a process can't open /proc/self/fd it > resorts to closing every possibly open file descriptor up to its > rlimit. I fixed pseudofs to enable linprocfs to dynamically populate > /proc//fd as a replacement for the soft link to /dev/fd (using > fdescfs for this purpose is broken in a number of respects). I'm now > hitting other issues running apt from xenial, but at least it no > longer does this. One could easily add a sysctl node, e.g. > proc.self.fd, for any of the procfs features that ported apps rely on. > I will try that procfs -trick and see if it affects anything :D > > > All these problems started a few years ago, cannot remember when. > > > > There are two PRs about these hard and soft crashes, but nobody has > done > > anything to fix them. See here: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204454 <-- > frequent > > tab crashes (soft crash) > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207298 <-- > > kickstarter.com crashes (hard crash) > > > > The maintainers just keep updating the www/chromium port and hope > that > > some newer version would make these issues go away, but I think the > > problem is deeper than that. Probably something to do with the > > behavioural differences of syscalls between FreeBSD and Linux. Such > > problems will not go away over version upgrades. > > > > I've done some of debugging myself, and figured out that the the > SIGSEGV > > is triggered somewhere in libstdc++. But I cannot fix these issues > > because I am not familiar with the Chromium codebase, Linux vs > FreeBSD > > syscall differences or even stdc++ specific issues. > > > Unfortunate. Right now during non-networking time I'm most interested > in getting Xenial's userland up and running chrooted under > /compat/linux. This is initially to get Intel GPU Tools working so I > can diagnose issues in i915 - but longer term so that we can run > commercial applications like Steam and the NFLX browser client > (widevine DRM is Linux only). After that I'll take a look at native > Chromium issues as that falls under the auspices of my personal > "enabling dogfooding" initiative. Awesome! I totally agree that the only way to get FreeBSD working on desktop is to actually get people using it as a desktop. Like the OpenBSD guys do. This way the developers and maintainers can get enough PRs with useful data to go forward with fixing solutions. > > Also, Firefox doesn't work properly, it starts using 100% CPU after > few > > hours of use. Again, no solutions, not enough PRs, nobody fixing the > > problem. There was some issue with the oss sound backend, but having > it > > fixed still does not rectify the overall slowdown issue. We cannot > even > > figure out where Firefox uses all the CPU because the FreeBSD > version of > > Firefox does not support profiling at all. The compile time option > > PROFILE does absolutely nothing. > > > I actually have qualms with FF myself. With the new driver YouTube > doesn't work and WebGL demos don't animate unless the user is moving > the mouse. These are both symptoms that the browser isn't seeing > vblank notifications. However, unlike chromium, FF does not directly > access the /dev/dri/card0 device, so presumably it is talking to a > helper application. I have no idea how this works. I need someone with > a basic architectural understanding of FF to provide me with guidance. > Barring that, FF will become a second class citizen and will need to > be compiled with gpu acceleration disabled when DRM4.x displaces the > DRM3.8 in HEAD. Firefox is a huge blob of software. We would need help from somebody who knows the general architecture, yes. Not sure if the Mozilla upstream would help if asked nicely? > > Ergo, there are no stable, modern full featured browsers for FreeBSD > > users. Only unstable imports from Linux, pieced together with a > bundle > > of patches. > > > > If we are to get a decent browser for FreeBSD, one of two things > HAVE to > > happen: > > 1) a few FreeBSD developers become involved in Firefox and Chromium > > development, actually fixing these problems with communication and > > collaboration upstream > > or > > 2) somebody needs to create a modern, full featured browser > specifically > > for FreeBSD > > > > Not sure if any of these gonna happen any time soon. > > "Someone" (tm) needs to pick up the torch for #1. A browser developed > specifically for FreeBSD seems impractical and doesn't make any sense > to me. Next time someone asks "how can I contribute?" you have another > possibility to add to the list. > > > -M Heh, I've been asking developers to help with Chromium and FF debugging when I got the chance (which is rare, I am pretty anti-social). Nobody as of yet has had enough time or interest to start debugging and profiling Firefox on FreeBSD. I can understand, it is a huge task to undertake. We'll see what happens. Thank you very much for your technical analysis Mr. Macy. Much appreciated ... at least now I have a bit more knowledge about what's going on with the browser situation. Also I much appreciate the work you are doing to update the graphics stack in FreeBSD! Thank you for your efforts :) After I get home from work I am going to try if Epiphany works any better than chrome/FF. The current Epiphany port actually uses Webkit2, instead of Webkit, which has similar process isolation model to Chrome. Maybe that would make Epiphany fast enough to use Youtube with :P -- Arto Pekkanen From owner-freebsd-chromium@freebsd.org Sat Jul 9 18:36:31 2016 Return-Path: Delivered-To: freebsd-chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04B0EB84654 for ; Sat, 9 Jul 2016 18:36:31 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E97341E61 for ; Sat, 9 Jul 2016 18:36:30 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id E8C48B84652; Sat, 9 Jul 2016 18:36:30 +0000 (UTC) Delivered-To: chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E86EEB84651 for ; Sat, 9 Jul 2016 18:36:30 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C57921E60 for ; Sat, 9 Jul 2016 18:36:30 +0000 (UTC) (envelope-from mmacy@nextbsd.org) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1468089382624291.65855564228525; Sat, 9 Jul 2016 11:36:22 -0700 (PDT) Date: Sat, 09 Jul 2016 11:36:22 -0700 From: Matthew Macy To: "chromium" Message-ID: <155d0f236ad.c11b2673215986.622076744465197484@nextbsd.org> Subject: Chromium sandboxing on FreeBSD MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 18:36:31 -0000 How much of Chromium's sandboxing code actually works on FreeBSD? On Linux it relies in part on user namespaces which appear to be a much more modular equivalent of jails usable by unprivileged processes. Thanks. -M From owner-freebsd-chromium@freebsd.org Sat Jul 9 19:52:40 2016 Return-Path: Delivered-To: freebsd-chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CD1EB85FBA for ; Sat, 9 Jul 2016 19:52:40 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 47983170F for ; Sat, 9 Jul 2016 19:52:40 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 469E9B85FB9; Sat, 9 Jul 2016 19:52:40 +0000 (UTC) Delivered-To: chromium@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43FA0B85FB8 for ; Sat, 9 Jul 2016 19:52:40 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3072170E for ; Sat, 9 Jul 2016 19:52:39 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id f126so49473476wma.1 for ; Sat, 09 Jul 2016 12:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EIxGTTM5tML7yBpNeEizg5SoL672sBoLF8DJY5x3bWc=; b=jxDtKuXHZNUgbzymgDovtQUeAm1YU6jNd4CZWtwbOrAhKjafEEwqg6mEHrADrnlWJ9 ZYjnWRPG+okgYIIJeysKjlEeQjziSu8/3ZnfxmFyXHIro2nAaDVq+gAIR4HsTTBHNfrX z3oyX+MmPUZCXNwCspuPabGN2jzy96ZSwV49gjWuXCSehMCl3CJPD/D98UNdklDPTSOH 6Qea1nZhEH7oP+IG3RVBM6KxPO4T1/i88KoG31IkkkFvUlztvKyR3vv9xMcq1mKn7qdL 6fwjY95blFsrB+YrKZz5BYD0BfzrBbpTKKwIOeaAf2Z8wvBeryJ8b1LlL/C6j5HREax3 TeWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=EIxGTTM5tML7yBpNeEizg5SoL672sBoLF8DJY5x3bWc=; b=PDAF0Fq9I+ebzAsbRlPxHIXSofrt63CETp5gi7MmeHtTAxev/b5PhkH/sbc49mt6ft 6VrA5+LtRuR+JjPtvi4sEIMtsUV3Y8r0EMBOT4muMH4xUVt0XSz/HjNjTElvmbnwAzgt feV5Hh21ayQZyBzNVMdB5qjc9QvHeuNNpb5dabvoaqHX53+0I/nHs678r7q13FztEOvw qdrE/1X7aJETg5TYKVeyBoQSWroW3Z2a/pqqfFjhmoooyirCZ4kg/IpqrDssP73vKw+I FT56KCJ1rN+TddyCJkzGhLjt03JSbinQ3/IThk4j9y40Qn8gZI+XyMET93qALtFUI4vk cBTg== X-Gm-Message-State: ALyK8tJdDg9idwJYLvW5p/UCfEK54UgmTFIjUpsH5zuctguZe5gEmXyNWVnDcz+KlzRTQQ== X-Received: by 10.194.236.69 with SMTP id us5mr10661988wjc.165.1468093957225; Sat, 09 Jul 2016 12:52:37 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id hf7sm2744092wjc.48.2016.07.09.12.52.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jul 2016 12:52:36 -0700 (PDT) Sender: Baptiste Daroussin Date: Sat, 9 Jul 2016 21:52:35 +0200 From: Baptiste Daroussin To: Matthew Macy Cc: chromium Subject: Re: Chromium sandboxing on FreeBSD Message-ID: <20160709195235.rrfflo3tsho7by76@ivaldir.etoilebsd.net> References: <155d0f236ad.c11b2673215986.622076744465197484@nextbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fow5w7azsxx3evfe" Content-Disposition: inline In-Reply-To: <155d0f236ad.c11b2673215986.622076744465197484@nextbsd.org> User-Agent: Mutt/1.6.1-neo (2016-06-11) X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 19:52:40 -0000 --fow5w7azsxx3evfe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 09, 2016 at 11:36:22AM -0700, Matthew Macy wrote: >=20 > How much of Chromium's sandboxing code actually works on FreeBSD? On Linu= x it relies in part on user namespaces which appear to be a much more modul= ar equivalent of jails usable by unprivileged processes. People working on chromium (now, I'm not anymore) would know better but Goo= gle sponsored capsicum development for sanboxing chromium, there are lots of talks/papers available out there explaining that. But on the otherside upst= ream never accepted (or almost never accepted) our patches to run on freebsd resulting in the current ports as now contain 395 patches to run there. So = the capsicum patches were never integrated neither upstream neither on freebsd.= =2E. btw big thanks to the people working on keeping chromium working on FreeBSD given how unfriendly upstream is... Google chrome team is not friendly to projects which are not Linux, Windows= or Mac OS. Best regards, Bapt --fow5w7azsxx3evfe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXgVYDAAoJEGOJi9zxtz5ayyAQAMJI5uqj9EeY/hAAb3gQNvNr U4IWfyTsZzT1M7IFOqUNfMVUs1GE5LjZ9L7USroEojKix44kJ2gFg6XsKRgM9ETa WaO2qARsUgbQkFeWBfvi1pmcvV/KLBzZpl/CsncnaZ9H329w7fvkU09qodVtMSFA 57rla6e73bgXocuekk9yvVc+abJUCze4HWgsRdmG/d8FQnuO63KWjPVXZAfOrczs 5eWF/cchBYiXbkUNGHQVHdVvyZ+ww32J2cy4octRa9MPxS5dvDxaVzZLpezGDbzq 5788CkjYO/AS769wVvpRq/Gbo4s0tqXy7ksZgrW25CH8TJ/5G1dX/K0sJ+QUHWoo 7zZKeZfgjRrl3u6/JLNs6CHPQBkebl4Uyl8ZqDnu5+9QYskp7eOpwE5TWBni+gxw 8dSeazVHUV3FgVfgqp8v0TE7QHGLld8HUax9rwADwnmKwKHHSahZ0k2QM5G8EXqY Ls35E+AlsE74la+hhT3sRWpy1WrUSVRKayFrLZdSi9wizUXR5xl9iW4w5RMEWO0T ZYi7OCEN+YixDwenRQQHMoUdgUf1DC9jefTeiU+Bx8IGo8gcvqaVBoY+9i43rAKu dAQd4ZtT5vU6K9DB7s6WJJTFsR4VA9fh89JftVU8Den2gytE6zaGBO0MIDPKHPL9 3g9u51ik8BxkBAJ2/KA9 =d3rZ -----END PGP SIGNATURE----- --fow5w7azsxx3evfe--