Summary: | >=www-client/chromium-53[gn] with system libevent causes various instabilities | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nick <nickAristocrates> |
Component: | Current packages | Assignee: | Chromium Project <chromium> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | alex, bkohler, che, const, Dagobertstaler, dblaci, dominik, eugene.nikolaev, fordfrog, gl, graham, grzegorz.kubiak, mike, mmk, pacho, panard, thomas.bettler |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=593458 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
using system libevent header
bootstrap with system libevent and don't use base/third_party/libevent/event.h |
Description
Nick
2016-08-23 17:05:50 UTC
I don't think gn would have anything to do with this. It's possible tcmalloc and/or suid might have some effect on extensions. I mentioned gn mostly because it currently appears to force -tcmalloc # TODO: bootstrapped gn binary hangs when using tcmalloc with portage's sandbox. REQUIRED_USE="gn? ( gnome gnome-keyring !tcmalloc )" Testing with +suid did not change anything, are there plans to support +gn +tcmalloc without FEATURES=-sandbox soon? Created attachment 444220 [details, diff]
using system libevent header
Comment on attachment 444220 [details, diff]
using system libevent header
What issue is this patch intended to address? Why is it attached to this bug report?
i getting "page hang" aswell. www-client/chromium-54.0.2832.2 with +gn -tcmalloc i don't use any adblock or any other extensions. i have the same issue. happens for me mostly with facebook.com, roundcube website and jira website. With https://gitweb.gentoo.org/repo/gentoo.git/commit/www-client/chromium?id=2721606ff5b384d36220d9f2702d5984a4cc11e1 it should be possible to use tcmalloc with GN. If you'd like to help with debugging the -tcmalloc case, please follow https://chromium.googlesource.com/chromium/src/+/master/docs/linux_debugging.md and upload some symbolized stack traces of the hanging processes. yesterday i compiled chromium with following use flags including +tcmalloc but the issues persist: [ebuild R #] www-client/chromium-54.0.2840.6::gentoo USE="cups (gn) gnome gnome-keyring hangouts (pic) proprietary-codecs pulseaudio suid tcmalloc -custom-cflags (-gtk3) -kerberos (-neon) (-selinux) -system-ffmpeg {-test} -widevine" L10N="cs -am -ar -bg -bn -ca -da -de -el -en-GB -es -es-419 -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt-BR -pt-PT -ro -ru -sk -sl -sr -sv -sw -ta -te -th -tr -uk -vi -zh-CN -zh-TW" 0 KiB The issues may be caused by given version of the browser, not USE flags. 1. Could you try to obtain a stack trace of hung processes using instructions from https://chromium.googlesource.com/chromium/src/+/master/docs/linux_debugging.md ? 2. Can you repro the issues with google-chrome? I'm glad I'm not the only person seeing this, I've tried compiling chromium with both gcc and clang to no avail, it's an issue in both the 54 & 55 series. It doesn't seem to be an issue with the binary packages however I'm currently compiled with: www-client/chromium-55.0.2853.0::gentoo USE="cups custom-cflags (gn) hangouts (pic) proprietary-codecs pulseaudio suid system-ffmpeg tcmalloc widevine -gnome -gnome-keyring (-gtk3) -kerberos (-neon) (-selinux) {-test}" L10N="en-GB -am -ar -bg -bn -ca -cs -da -de -el -es -es-419 -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -nl -pl -pt-BR -pt-PT -ro -ru -sk -sl -sr -sv -sw -ta -te -th -tr -uk -vi -zh-CN -zh-TW" When I compile with -suid on 54.*.*.* and 55.*.*.* I get a segmentation fault when starting chromium. Please mask chromium-54, it is highly unstable, the use flags dont matter. I have been experiencing the same issues (randomly but frequently hung tabs) with 53.*, when compiling with GN. A soon as I disabled the GN use flag and fell back to GYP, it worked. Now 54.0.2840.16 is compiling with GN only, I have the same problem again, just like you. In all cases I was compiling with +tcmalloc and +suid and various combinations of gcc, clang / bfd, gold, lld / no LTO, normal LTO, thin LTO, but the results were always the same (also the vanilla combination of gcc, bfd, no LTO). Interesting thing was, I already had it with 53.* when using GN. the issue still persists in www-client/chromium-55.0.2853.0 aswell. i have downgraded to www-client/chromium-53.0.2785.101 with USE="-gn" and everything works fine again. I too am seeing this issue, in particular with extensions. Trying to open up options dialogs for extensions leads to a hang on the page load, and enabling anything, adblock plus or otherwise causes many pages to just say "waiting on extension [so and so]". Hi, I also have this problem (plus a font size problem on tabs) since gn is for ninjabuild files (https://chromium.googlesource.com/chromium/src/tools/gn/) could it be a problem with dev-utils/ninja ? I'm willing to update ninja to 9999 to see how it goes would any of you advise against it ? Thanks for your time and answer (In reply to Tanki from comment #18) > Hi, > I also have this problem (plus a font size problem on tabs) > since gn is for ninjabuild files > (https://chromium.googlesource.com/chromium/src/tools/gn/) could it be a > problem with dev-utils/ninja ? > I'm willing to update ninja to 9999 to see how it goes > > would any of you advise against it ? > > Thanks for your time and answer I doubt it has anything to do with ninja: The old build system also was using ninja. GN is just another way to generate the ninja build files, just as GYP which was used before. My current guess is that GN is generating ninja build files that differ from those generated by GYP in a way that's causing this behaviour, as it already occured in M53 builds always when using GN, never when using GYP. If anyone has time could they diff the build directory with and without the gn flag on the 53 build (which we know works with -gn) It might give a clue as to whats broken - I'll try playing around with the build tonight +tcmalloc: unstable, -tcmalloc: unstable, +suid: unstable, -suid: unstable Seems chromium-54 is just unstable. The use flags don't make a difference. Please mask. google-chrome 54 and 55 seem quite usable, and those are built using GN. I don't think there is anything inherently broken about it. I suspect there is some issue with an unbundled system library, or a toolchain issue of some sort. (In reply to Mike Gilbert from comment #22) > google-chrome 54 and 55 seem quite usable, and those are built using GN. I > don't think there is anything inherently broken about it. > > I suspect there is some issue with an unbundled system library, or a > toolchain issue of some sort. I did an emerge -e chromium and it has not changed the problem I was facing I also make sure everytime I upgrade my system I use the option --with-bdeps Although everything compiles fine, chromium still takes frickin' ages to display a simple webpage, and display nothing while I use Ublock Origin (or any adblocker for that matter...) and all this happens since the introduction of the mandatory gn use flag commit b69d5c8c5e30f9466cddc591703bf16584d5bf20 Author: Mike Gilbert <floppym@gentoo.org> Date: Tue Sep 13 11:13:27 2016 -0400 profiles: mask chromium-54 profiles/package.mask | 6 ++++++ 1 file changed, 6 insertions(+) Yeah forgot to add this behavior also happens with chromium-55* is there a way to remove the gn flag apart from altering the ebuild ? if so please advise The gn flag controls how the ninja build files are created, gn is the new way gyp is the old way. By the looks of things Google have stopped working on gyp, as Chromium no longer builds. I'm sure if you put some effort in you could fix it for the current build but going forward this will be more difficult to maintain. When the first release of 54 appeared in portage there were patches to make it build with gyp, I still had issues with the resulting binary. I don't think this is a build system issue. today i merged www-client/chromium-55.0.2859.0 and so far it works pretty good, no freezes. i found only two issues: 1) i cannot load pages from websites like https://pb.one2one.cz/ which are running tomcat 8.5.5 behind with http2 support (not sure it is related or not). this issue is new since version 55 (not sure which build exactly). i did not find the cause or more detail info to this issue. 2) when using facebook.com, new messages appear in system notification window but facebook page does not display the message unless i reload the whole page, but this issue exists at least since version 53 (still using gyp) and so it is not related to this issue. (In reply to Miroslav Šulc from comment #27) Thanks for the feedback. chromium-54.0.2840.27 contains the same "fix" (bundled libevent) and is unmasked. I wonder if using libevent-2.1.6 fixes the issue with the system version Created attachment 446050 [details, diff]
bootstrap with system libevent and don't use base/third_party/libevent/event.h
build.log:
g++ .... -I../.. -Igen .... -Igen/shim_headers/libevent_shim -c ../../base/message_loop/message_pump_libevent.cc -o ....
g++ .... -I../.. -Igen .... -Igen/shim_headers/libevent_shim -c ../../third_party/webrtc/base/task_queue_libevent.cc -o ....
default_include_dirs (-I../..) is on the left of shim_headers_path (-Igen/shim_headers/libevent_shim)
g++ will use: ../../base/third_party/libevent/event.h
and ignore: gen/shim_headers/libevent_shim/base/third_party/libevent/event.h
So we should not preserve "base/third_party/libevent/event.h"
*** This bug has been marked as a duplicate of bug 593458 *** |