Date: Fri, 08 Jul 2016 14:45:31 +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: <24ab4a7e5d956cb4f0198951e4fbc896@kapsi.fi> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24ab4a7e5d956cb4f0198951e4fbc896>