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

[Arto Pekkanen]

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/<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.
> 

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