chrome spends all its time calling close Re: chrome spends all its time calling open

[Arto Pekkanen]

Matthew Macy kirjoitti 03.07.2016 03:24:
> Subject line was wrong.
> 
> 
>  ---- On Sat, 02 Jul 2016 17:23:18 -0700 Matthew Macy
> <mmacy at 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