Date: Wed, 06 Jul 2016 17:13:33 +0300 From: Arto Pekkanen <isoa@kapsi.fi> To: Matthew Macy <mmacy@nextbsd.org> Cc: chromium <chromium@freebsd.org> Subject: Re: chrome spends all its time calling close Re: chrome spends all its time calling open Message-ID: <23d62c1559ad130b7ae7f812ad7f0a0c@kapsi.fi> In-Reply-To: <155ae2426da.ecd708a055370.6844710089510046027@nextbsd.org> References: <155ae2351dc.d435e15355364.689950361019774764@nextbsd.org> <155ae2426da.ecd708a055370.6844710089510046027@nextbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23d62c1559ad130b7ae7f812ad7f0a0c>