Date: Wed, 06 Jul 2016 11:50:22 -0700 From: Matthew Macy <mmacy@nextbsd.org> To: "Arto Pekkanen" <isoa@kapsi.fi> Cc: "chromium" <chromium@freebsd.org> Subject: Re: chrome spends all its time calling close Re: chrome spends all its time calling open 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>
next in thread | previous in thread | raw e-mail | index | archive | help
---- On Wed, 06 Jul 2016 07:13:33 -0700 Arto Pekkanen <isoa@kapsi.fi> wrote ----
> Matthew Macy kirjoitti 03.07.2016 03:24:
> > Subject line was wrong.
> >
> >
> > ---- On Sat, 02 Jul 2016 17:23:18 -0700 Matthew Macy
> > <mmacy@nextbsd.org> 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/<pid>/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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?155c18bf4bc.df8f34f148837.2668232318689911733>