Bug 212812 - www/chromium: tabs "hang" 10% of the time
Summary: www/chromium: tabs "hang" 10% of the time
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-chromium mailing list
URL: https://bugs.chromium.org/p/chromium/...
Keywords: regression
: 204454 216039 226720 (view as bug list)
Depends on: 226793
  Show dependency treegraph
Reported: 2016-09-19 07:08 UTC by Edward Tomasz Napierala
Modified: 2018-11-04 14:21 UTC (History)
40 users (show)

See Also:
bugzilla: maintainer-feedback? (chromium)


Note You need to log in before you can comment on or make changes to this bug.
Description Edward Tomasz Napierala freebsd_committer 2016-09-19 07:08:01 UTC
Since the upgrade few weeks ago, opening a tab and loading the page can result in the tab "hanging".  This occurs when loading a page.  The effect is that the page contents cannot be scrolled, the page is completely unresponsive, and the "spinner" continues spinning - just like when loading.  After a while the "page is unresponsive" popup pops up.  Choosing to kill the page and reloading it usually works.
Comment 1 bkarp 2016-09-19 10:28:42 UTC
Confirming that I see the same hanging tab behavior on 10.3-RELEASE p7, with chromium-52.0.2743.116 built from source from ports on 2016-08-13.

This behavior is a significant work stopper for me: as I open an increasing number of tabs (~15 or so), the chance of a tab's hanging increases to in excess of 75% (and greater the longer the tab is open and interacted with).
Comment 2 Thomas Zander freebsd_committer 2016-10-23 12:16:07 UTC
This is indeed becoming worse with every build. With 52.0.2743.116 on stable/11 amd64 it even often hangs when opening the very first tab. My first thought was because of extensions, but I can happily reproduce the problem with the official package and a newly created profile. Any ideas?
Comment 3 Edward Tomasz Napierala freebsd_committer 2016-10-27 09:50:24 UTC
I wonder if this didn't happen before because of older Chromium, or because of the older FreeBSD.  In other words - does it also happen with current Chromium, but eg FreeBSD 10.2 or 10.1?
Comment 4 Carlos J. Puga Medina freebsd_committer 2016-10-28 15:15:40 UTC
It should be fixed after chromium update to 54.0.2840.50.

I'm testing it now and chromium works fine at the moment.

% pkg info chromium
Name           : chromium
Version        : 54.0.2840.50
Installed on   : Fri Oct 28 00:42:29 2016 CEST
Origin         : www/chromium
Architecture   : freebsd:10:x86:64
Prefix         : /usr/local
Categories     : www
Licenses       : MPL and LGPL21 and BSD3CLAUSE
Maintainer     : chromium@FreeBSD.org
WWW            : http://www.chromium.org/Home
Comment        : Google web browser based on WebKit
Options        :
	CODECS         : on
	DEBUG          : off
	DRIVER         : off
	GCONF          : on
	KERBEROS       : on
	PULSEAUDIO     : off
	TEST           : off
Shared Libs required:
Annotations    :
	cpe            : cpe:2.3:a:google:chrome:54.0.2840.50:::::freebsd10:x64
Flat size      : 175MiB
Description    :
Chromium is an open-source browser project that aims to build a safer,
faster, and more stable way for all users to experience the web.

The Chromium website contains design documents, architecture overviews,
testing information, and more to help you learn to build and work with
the Chromium source code.

WWW: http://www.chromium.org/Home

Note that we're working to commit the update into the ports tree.
Comment 5 Ori Bernstein 2016-11-12 08:14:42 UTC
Also happens for me on FreeBSD 11, Version 54.0.2840.90 (64-bit). This was not a problem on 51.0.2704. I skipped 52.0.x because of rendering issues.
Comment 6 bkarp 2016-11-12 14:40:00 UTC
FWIW, I'm running chromium 54.0.2840.100 on amd64 (built from https://github.com/gliaskos/freebsd-chromium as of last night) on FreeBSD 11.0-RELEASE, and I've just had a tab hang for me in exactly the same way it did in the most recent version of the port.

Same symptoms reported in this bug: "spinner keeps spinning," eventually a dialog saying that the page is unresponsive pops up.

Comment 7 Jonathan Chen 2016-11-22 02:16:00 UTC
On an updated ports tree, r426611 2016-11-21 07:49:58 +1300, my build of chromium current loads partially on facebook.com before stopping with a "page is unresponsive" result.
Comment 8 Carlos J. Puga Medina freebsd_committer 2016-11-23 10:20:26 UTC
Probably, it's a good idea to remove .config/chromium folder after a fresh install.

I had a lot of unresponsive pages and partly this fixed my problem.
Comment 9 Jonathan Chen 2016-11-23 18:33:30 UTC
I've updated to chromium 54.x, and this appears to be a lot better than the 52.x series. So far, the "hang" rate has been reduced to just once a day..
Comment 10 Ori Bernstein 2016-11-26 21:28:45 UTC
Seems to be an issue talking to the render thread.

If it helps, I have an nvidia gpu.

$ bt
#0  _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
#1  0x0000000807e58aa6 in _thr_umtx_timedwait_uint (mtx=0x808072ed0, id=<optimized out>, clockid=<optimized out>, abstime=<optimized out>, shared=0) at /usr/src/lib/libthr/thread/thr_umtx.c:
#2  0x0000000807e62510 in cond_wait_user (abstime=0x0, cancel=1, cvp=<optimized out>, mp=<optimized out>) at /usr/src/lib/libthr/thread/thr_cond.c:294
#3  cond_wait_common (cond=<optimized out>, mutex=<optimized out>, abstime=0x0, cancel=1) at /usr/src/lib/libthr/thread/thr_cond.c:354
#4  0x0000000005790c28 in mojo::edk::Waiter::Wait(unsigned long, unsigned long*) ()
#5  0x0000000005775f8d in mojo::edk::Core::WaitManyInternal(unsigned int const*, unsigned int const*, unsigned int, unsigned long, unsigned int*, mojo::edk::HandleSignalsState*) ()
#6  0x0000000005775c7e in mojo::edk::Core::Wait(unsigned int, unsigned int, unsigned long, MojoHandleSignalsState*) ()
#7  0x00000000054ba9c9 in mojo::SyncHandleRegistry::WatchAllHandles(bool const**, unsigned long) ()
#8  0x00000000054af362 in IPC::SyncChannel::WaitForReply(mojo::SyncHandleRegistry*, IPC::SyncChannel::SyncContext*, bool) ()
#9  0x00000000054aeeb4 in IPC::SyncChannel::Send(IPC::Message*) ()
#10 0x00000000063e0212 in non-virtual thunk to gpu::GpuChannel::Send(IPC::Message*) ()
#11 0x0000000007865b86 in content::RenderThreadImpl::Send(IPC::Message*) ()
#12 0x00000000044f076d in extensions::RuntimeCustomBindings::OpenChannelToExtension(v8::FunctionCallbackInfo<v8::Value> const&) ()
#13 0x00000000044ecdd6 in extensions::ObjectBackedNativeHandler::Router(v8::FunctionCallbackInfo<v8::Value> const&) ()
#14 0x00000000039cb1dc in v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) ()
#15 0x0000000003a2fdb0 in v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::int
rguments) ()
#16 0x0000000003a2f33d in v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) ()
#17 0x0000390c31e063a7 in ?? ()
#18 0x0000000003efe480 in ?? ()
#19 0x0000390c31e062e1 in ?? ()
#20 0x00007fffffff9300 in ?? ()
#21 0x0000000300000000 in ?? ()
#22 0x00007fffffff9398 in ?? ()
#23 0x0000390c31f25eca in ?? ()
#24 0x0000021a05f04311 in ?? ()
#25 0x0000084188e290c9 in ?? ()
#26 0x0000000700000000 in ?? ()
#27 0x0000021a05f04421 in ?? ()
#28 0x00000d783b0fefc1 in ?? ()
#29 0x00001309bce09cd9 in ?? ()
#30 0x00001309bce10901 in ?? ()
#31 0x0000084188e290c9 in ?? ()
#32 0x0000021a05f04311 in ?? ()
#33 0x0000021a05f04421 in ?? ()
#34 0x00000d783b0fefc1 in ?? ()
#35 0x00001309bce151c9 in ?? ()
#36 0x00001309bce12189 in ?? ()
#37 0x00007fffffff93d8 in ?? ()
#38 0x0000390c31e4a7c3 in ?? ()
#39 0x000007f92d31c559 in ?? ()
#40 0x00001309bce09cd9 in ?? ()
#41 0x00001309bce12cb1 in ?? ()
#42 0x0000032935db3661 in ?? ()
#43 0x0000390c31e4a6e1 in ?? ()
#44 0x0000000c00000000 in ?? ()
#45 0x00007fffffff9440 in ?? ()
#46 0x0000390c31e2aa81 in ?? ()
#47 0x0000000000000000 in ?? ()
Comment 11 timp87 2016-11-29 08:45:14 UTC
confirm thi
Comment 12 timp87 2016-11-29 08:46:06 UTC
There is similar bug report https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211036
Comment 13 timp87 2016-11-29 09:20:54 UTC
I'm getting such behaviour quiet often even on chromium-54.0.2840.100
.config/chromium was deleted 10 minutes ago.
Comment 14 Petr Fischer 2017-01-26 18:31:40 UTC
Hangs confirmed in chromium-55.0.2883.87 (11.0-RELEASE)
Comment 15 rick 2017-01-27 10:05:37 UTC
confirm +1
FreeBSD 12.0-CURRENT amd64
Comment 16 rick 2017-02-07 12:48:28 UTC
confirmed in
FreeBSD 12.0-CURRENT amd64
(of course with rm -rf ~/.config/chromium ~/.cache/chromium)
Comment 17 Jonathan Chen 2017-02-07 18:49:54 UTC
Still happens with chromium-56.0.2924.87, 11-STABLE/amd64

It's easy enough to reproduce when loading Facebook.
Comment 18 Elijah Crane 2017-02-09 12:38:37 UTC
12-current, chromium 56.0.2924.87
Chromium has no problems on system which was tuned for pgsql testload.

Sometimes page may freeze but may be closed w/o kill, as usual, with mouse-click :)
Comment 19 rick 2017-02-11 13:24:17 UTC
(In reply to Elijah Crane from comment #18)
I tried. It does not work for me.
FreeBSD 12.0-CURRENT amd64, chromium-56.0.2924.87_1
Comment 20 Petr Fischer 2017-02-12 13:13:00 UTC
I can confirm "Elijah Crane" - when page is freezed, you can kill it with tab close (red circle) button - tab is closed/killed after about 0.5s.

But - when I try to load the same web site (facebook, twitter) in fresh new tab, it's still freezing, maybe some running process (assigned to the site) is still freezed in background or something like this (it has nothing to do with "visual tab" IMHO).
Comment 21 roberto 2017-02-13 03:00:15 UTC
Disabling 'Hardware Acceleration' seems to solve the problem for me

(Settings -> Advanced -> System -> 'Use Hardware Acceleration when available' unchecked)

FreeBSD t420s 11.0-STABLE FreeBSD 11.0-STABLE #6 r313288: Sun Feb  5 17:36:18 CLST 2017     root@t420s:/usr/obj/usr/src/sys/T420S  amd64


GLX info:

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
    Version: 11.2.2
    Accelerated: yes
    Video memory: 1534MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
Comment 22 Jonathan Chen 2017-02-13 04:16:53 UTC
(In reply to roberto from comment #21)

Nope. I've just tried it with chromium-56.0.2924.87_1 on 11.0-STABLE/amd64 r313528, and I can say that disabling Hardware Acceleration still results in a hanging or partially rendered page.
Comment 23 roberto 2017-02-13 04:32:24 UTC
(In reply to Jonathan Chen from comment #22)

Unfortunately, i can confirm that. While i've found Chromium to be more stable without acceleration, it will still crash.
Comment 24 Tomo 2017-03-07 07:39:31 UTC
I use:

  Chromium 56.0.2924.87(pkg rev is 56.0.2924.87_1)

The "unresponsive & spinning spinner" problem was solved by following steps:

  1. Disable V8 cache
    Open chrome://flags and then,
      "V8 caching mode" -> set to "Disabled"

  2. Terminate chromium

  3. Clean up chromium's cache
     rm -rf ~/.cache/chromium

  4. Start chromium

In additional information, GPU accel keeps enabled on my environment.

  Extended renderer info (GLX_MESA_query_renderer):
      Vendor: Intel Open Source Technology Center (0x8086)
      Device: Mesa DRI Intel(R) Ironlake Mobile  (0x46)
      Version: 13.0.5
      Accelerated: yes
      Video memory: 1536MB
      Unified memory: yes
      Preferred profile: compat (0x2)
      Max core profile version: 0.0
      Max compat profile version: 2.1
      Max GLES1 profile version: 1.1
      Max GLES[23] profile version: 2.0

But, I guess that this problem is caused by hanging up HTML render for ANY reason(s). Therfore, I think that good idea to disable GPU accel etc, too.

I'm sorry for my bad English
Comment 25 Lars Engels freebsd_committer 2017-03-07 11:43:39 UTC
Woohoo, thanks a thousand times, tomo!

Works for me(TM)
Comment 26 timp87 2017-03-07 11:46:54 UTC
(In reply to Tomo from comment #24)

I'm really impressed. This even made by Chromium much faster!
Comment 27 Carlos J. Puga Medina freebsd_committer 2017-03-07 15:36:07 UTC
(In reply to Tomo from comment #24)

Code caching [1] was designed to reduce waiting time spent staring at a white screen, but especially on mobile devices.

By disabling this flag, prevents JavaScript scripts from being stored in cache.

I'm testing if chromium works much better than before.

Thanks Tomo!

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=399580
Comment 28 Jonathan Chen 2017-03-07 18:45:55 UTC
(In reply to Tomo from comment #24)

Thanks, Tomo! After using the browser for about 45 mins or so, I can confirm that the workaround appears to have resolved the issue for me. I have my Hardware Acceleration enabled, as that appears to make no difference.
Comment 29 Domagoj Stolfa 2017-04-07 21:57:37 UTC
Even with changes from Tomo, the tabs still end up hanging occasionally.
Comment 30 Atsushi Hasumoto 2017-05-13 02:06:53 UTC
I'm comfirm.
I use FreeBSD 11.0p10.
I imform Chromium --debug infomation.

the other site is linux(arch) infomation.

my debug infomation follow.

[3447:486629376:0513/105824.221841:ERROR:gles2_cmd_decoder_autogen.h(2916)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glTexParameteri: target was GL_FALSE
[3447:486629376:0513/105824.221860:ERROR:gles2_cmd_decoder_autogen.h(2916)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glTexParameteri: target was GL_FALSE
[3447:486629376:0513/105824.221907:ERROR:gles2_cmd_decoder_autogen.h(143)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[3447:486629376:0513/105824.221950:ERROR:gles2_cmd_decoder_autogen.h(143)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[3447:486629376:0513/105824.530679:ERROR:gles2_cmd_decoder_autogen.h(143)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[3447:486629376:0513/105824.530731:ERROR:gles2_cmd_decoder_autogen.h(143)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[3447:486629376:0513/105824.530753:ERROR:gles2_cmd_decoder_autogen.h(143)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[3447:486629376:0513/105824.530767:ERROR:gles2_cmd_decoder_autogen.h(143)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[3447:486629376:0513/105824.530782:ERROR:gles2_cmd_decoder_autogen.h(143)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[3447:486629376:0513/105824.530796:ERROR:gles2_cmd_decoder_autogen.h(143)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[3447:486629376:0513/105824.530812:ERROR:gles2_cmd_decoder_autogen.h(143)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[3447:486629376:0513/105824.530825:ERROR:gles2_cmd_decoder_autogen.h(143)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[3447:486629376:0513/105824.530848:ERROR:gles2_cmd_decoder_autogen.h(143)] [.DisplayCompositor-0x82c973e00]GL ERROR :GL_INVALID_ENUM : glBindTexture: target was GL_FALSE
[3447:486629376:0513/105824.530872:ERROR:logger.cc(46)] Too many GL errors, not reporting any more for this context. use --disable-gl-error-limit to see all errors.
[3447:486629376:0513/105828.674874:ERROR:gl_context_glx.cc(239)] Couldn't make context current with X drawable.
[3447:486629376:0513/105828.674970:ERROR:gpu_command_buffer_stub.cc(765)] Failed to make context current.
[3447:486629376:0513/105828.682702:ERROR:gl_context_glx.cc(239)] Couldn't make context current with X drawable.
[3447:486629376:0513/105828.682721:ERROR:gpu_command_buffer_stub.cc(765)] Failed to make context current.
[3447:486629376:0513/105828.863952:ERROR:gl_context_glx.cc(239)] Couldn't make context current with X drawable.
[3447:486629376:0513/105828.864129:ERROR:gpu_command_buffer_stub.cc(765)] Failed to make context current.
[3447:486629376:0513/105828.910764:ERROR:gl_context_glx.cc(239)] Couldn't make context current with X drawable.
[3447:486629376:0513/105828.910858:ERROR:gpu_command_buffer_stub.cc(765)] Failed to make context current.
[3447:486629376:0513/105828.920294:ERROR:gl_context_glx.cc(239)] Couldn't make context current with X drawable.
[3447:486629376:0513/105828.920316:ERROR:gpu_command_buffer_stub.cc(765)] Failed to make context current.
[3447:486629376:0513/105828.941250:ERROR:gl_context_glx.cc(239)] Couldn't make context current with X drawable.
[3447:486629376:0513/105828.941346:ERROR:gpu_command_buffer_stub.cc(765)] Failed to make context current.
[3447:486629376:0513/105840.639804:ERROR:gl_context_glx.cc(239)] Couldn't make context current with X drawable.
[3447:486629376:0513/105840.639903:ERROR:gpu_command_buffer_stub.cc(765)] Failed to make context current.
[3447:486629376:0513/105840.662085:ERROR:gl_context_glx.cc(239)] Couldn't make context current with X drawable.
[3447:486629376:0513/105840.662218:ERROR:gpu_command_buffer_stub.cc(765)] Failed to make context current.
[3447:486629376:0513/105840.685120:ERROR:gl_context_glx.cc(239)] Couldn't make context current with X drawable.
[3447:486629376:0513/105840.685175:ERROR:gpu_command_buffer_stub.cc(765)] Failed to make context current.
[3447:486629376:0513/105840.789167:ERROR:gl_context_glx.cc(239)] Couldn't make context current with X drawable.
[3447:486629376:0513/105840.789618:ERROR:gpu_command_buffer_stub.cc(765)] Failed to make context current.
Comment 31 VK freebsd_triage 2017-08-12 10:40:40 UTC
I'll second what Domagoj said, this is still happening, although in my case it's way more than 10% of occasions.
Comment 32 Adam Schaefers 2017-10-21 01:33:50 UTC
I experience this bug at least 50% of my tabs at any given time. Freebsd 11-1 release and chromium Version 61.0.3163.100 (Developer Build) (64-bit)

Disabling hardware acceleration and also Tomo's method did nothing for me.

If you would like me to try anything or if there is any specific information that would be helpful, please contact me sch@efers.org

Thank you.
Comment 33 Vince Mulhollon 2017-11-02 15:13:34 UTC
Problem seems to be getting worse over the last few months and last few upgrades, to the point I've had to switch to Firefox recently now that tab rendering success rate is well below 10%.

With no change in rate of tab rendering failure I have tried the following from the bug report:

Disable V8 caching in chrome://flags (which also takes 10-20 attempts to render)

Wipe .config/chromium (multiple times... first time I did that I wiped over a gig of junk)

Disable hardware acceleration in chrome://settings "Use hardware Accleration when available"

Multiple machines: I have three desktops using NFS home / LDAP etc so its trivial to try chromium across multiple machines, all with identical problems.

I had various older proprietary nvidia driver software on my multiple machines, I've upgraded the machines multiple times since the problem began per nvidia-smi as of today I'm running the latest "Driver Version: 384.59" and there is no change in tab hanging.

Because I have multiple different machines on the desk I've experienced the same failure on six nvidia cards of various ages and models: two older (circa 2014) geforce gtx 730 connected via analog vga 1280x1024, one ancient (circa 2011) geforce gtx 560ti DVI connection 1600x1200, and three new (circa 2017) geforce gtx 1050ti displayport connection 2560x1440 144 hz.  I have no hardware problems running CPU/GPU intensive workloads for hours without any crashes such as firefox or minecraft.  The bug I'm experiencing is solely related to chromium tab opening failing 90%+ of the time; never a graphics (or other subsystem) hang or kernel crash.  I can and do run onshape.com for hours in firefox, which is an online html5 professional CAD program which would seem to torture test 3d graphics rendering and hardware acceleration in a html5 browser.  I have an onshape CAD drawing open in another tab in firefox while I'm typing this; flawless operation, at least in firefox.  Whatever is wrong, it probably doesn't relate to graphics hardware or hardware acceleration or graphics drivers given that chromium hangs the same way and same rate of failure regardless of whatever hardware I throw at it; admittedly I don't have access to any non-nvidia graphics hardware.

I've tried a couple combinations of the above ; old card with disabled hardware and disabled caching but latest driver, wipe the config and no caching but enable hardware, sorry but I didn't record all my mixtures of experiments.  No change in failure rate under any condition.

One of the machines has front mounted drive trays; stick a drive tray boot drive with a SSD with devuan (basically, a debian distro) linux installed and everything works with every nvidia hardware card.  Ditto win10 and win7.  I don't have drive trays on the other two freebsd machines.

I find it fascinating that the failure rate is not 100% or 0% but is roughly 90% and for a given version of chromium regardless of hardware, the rate of failure in the long run is constant regardless of what I try, a sparse and graphically bare intranet of a couple K of pure html and CSS and no JS fails equally often as some social networking site with 5 megs of spyware and ad links and JS.  I opened and closed a gmail tab on another machine on my desk in chromium 13 times before it worked, whereas the intranet took 8 tries, but I've seen those numbers reverse before.  The standard deviation is very high, sometimes (although VERY rarely) tabs render in as little as three attempts.  Its been a long time since a chromium tab renders on the first try; maybe a year now.

All three machines are running SSDs.  Two have 1/4 tb raid1 mirror arrays with zfs; the third drive tray machine has a 120 GB SSD for freebsd.  Two machines have 16 GB of RAM one has 8 GB.  I'm playing with one machine as I'm typing this, trying to open a gmail window and top reports 2925M free with 0 swap use; whatever's wrong its not because its starved for memory or cpu load is too high.  All three motherboards are older AMD64.

I work in a secured "armed guard" type of environment, so once I got a tab to gmail to work, I was able to leave the tab open and running on a physically secured machine; once a tab initially renders, if it doesn't hang when opened of course, performance is excellent and there are no weird crashes even after days of continuous use of the same tab.  No slowdowns, no bugs, no weird rendering, no kernel crashes, no weird syslog lines, no memory leaks (none that hit within a week or two anyway)  Either it fails to begin to render or it works and that one tab will continue to work for at least a week of continuous use.

I have access to an extremely large vmware cluster so this morning I spun up a freebsd host on the dev vlan and installed chromium 61.0,3163.100_1 ... I can connect to the vmware image using rdesktop and its slow but tabs work 100% of the time.  That is interesting because its the same OS with the same ansible-enforced packages configuration and installation but if it runs on bare hardware the chromium render hangs, but if I run it on virtualized hardware it works perfectly (well, slowly as you'd expect...)  Neither ansible nor the OS "know or care" that one machine is bare metal hardware and the other machine is a virtual image, from an ansible configuration standpoint the only difference between the three bare metal installs on my desk and the virtual image on the cluster is ip addrs and hostname.  Obviously the hardware is different; the cluster is intel hardware and the cluster image devices are virtual not bare metal and silicon.

dmesg on the identical ansible-configured virtualized image reports "vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0".  /var/log/Xorg.0.log reports its using the vmware x11 driver "[    11.742] (--) vmware(0): VMware SVGA regs at (0x1070, 0x1071)"  I believe there is a way to pass thru GPU access to a vmware image and I'm obviously not doing that.

The fact that chromium renders tabs fine when an identical image is virtualized and run without the nvidia driver, connected via a rdesktop session, would seem to point to the nvidia driver GPU acceleration as the problem, although the nvidia driver operates perfectly with all other software on the machine including extremely graphically intensive software and the only symptom of any sort ever is creating tabs fails to render almost all the time only on chromium seems to point to a problem with how chromium talks to nvidia driver WRT some kind of hardware acceleration that cannot be disabled from options in the browser config.  Its also odd that the driver fails only 90% of the time and the failure rate appears unrelated to system workload or complexity/size of the page to be rendered or physical nvidia card hardware model.

I wonder if I opened 100000 tabs, using some kind of GUI automation software that might not even exist, if the failure rate converged to 15/16th of the time.  If when opening a tab, some random stack address or something has to randomly line up precisely on a perfect 16 byte address boundary or it locks up the thread.  I wouldn't even know where to begin to look, but I do have a gut level feeling the failure rate, if it could be measured, is currently exactly 15/16th of the time, and somewhere a 128 bit long "something" is only being stored correctly 1/16th of the time.

If anyone has any ideas or suggestions for experiments, please advise.  I'm outta ideas, and firefox works great, and the only reason I care anymore is my chromebook uses chrome so it would be nice to sync my desktop and my chromebook bookmarks, whatevs...

Have a pleasant day and thanks for your efforts thus far and in the future and good luck with this tricky bug!
Comment 34 Rob Belics 2017-11-02 17:15:36 UTC
(In reply to Vince Mulhollon from comment #33)
I've had to do the same but, being a web dev, I must use chromium for testing. What I've found is, if I leave chromium running in one window (I have the bookmarks manager in that) and open a second window, I can often surf for quite a while, even with multiple tabs, before having problems.
Comment 35 Thomas Zander freebsd_committer 2017-11-05 13:01:41 UTC
There must be some timing / locking related component to this problem.
On my desktop (11/stable, sandybridge w/ integrated graphics) these hangs can easily triggered just by firing load onto the CPUs. As long as at least one CPU is fairly idle, the hangs happen rarely. As soon as the load tips above 1.0 per CPU, it is merely a matter of minutes (or seconds even) until a hang occurs.
Comment 36 timp87 2018-02-26 08:18:14 UTC
Unfortunately, chromium is now almost totally unusable with 63.0.3239.132 version :(
Comment 37 Carlos J. Puga Medina freebsd_committer 2018-02-27 08:41:19 UTC
(In reply to timp87 from comment #36)

chromium works fine on 10.3/amd64, I didn't notice the tabs hanging issue since I bumped up the maximum number of open files via sysctl.conf(5)


Other relevant variables that I have changed


# Boot-time kernel tuning


# Maximal (lowest) priority for preemption
# give more responsiveness on desktop
Comment 38 Grzegorz Junka 2018-02-27 08:53:46 UTC
This looks like a duplicate of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204454 (since 204454 was opened earlier). Also, similar issues were reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186352 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211202 - can someone please add these to the See Also section?
Comment 39 timp87 2018-02-27 09:13:58 UTC
(In reply to Carlos J. Puga Medina from comment #37)
I've just tried these parameters on my FreeBSD 11.1-RELEASE amd64 workstation. Nothing changed, chromium tabs hang as before.
Comment 40 bourne.identity@hotmail.com 2018-02-27 09:57:40 UTC
Chromium (61.0.3163.100 (Developer Build) (64-bit)) seems to work fine for me now on FreeBSD 10.3. Pages and tabs don't hang. But I seem to have lost the tab for Extensions via the application's menus. I have to use chrome://extensions to open up the Extensions tab.
Comment 41 Carlos J. Puga Medina freebsd_committer 2018-02-28 12:13:09 UTC
(In reply to timp87 from comment #39)

The kern.maxfiles sysctl variable should change according to the workload of your machine, the number of services running concurrently, etc.

These are not absolute values, so try using larger values.

Comment 42 timp87 2018-02-28 12:20:35 UTC
(In reply to Carlos J. Puga Medina from comment #41)
Sure. In my workload it hardly matters.
Comment 43 Rob Belics 2018-02-28 12:26:12 UTC
(In reply to Carlos J. Puga Medina from comment #37)

I tried those values and one tabs crashed almost immediately. However, since then, chromium seems to be running well. 

That said, I've noticed two things. 1) Facebook would hang with a spinner in the tab and I could not get the drop down to drop down for signing out. I noticed the spinner on reddit (blech), too, But if I had web developer tools open, everything on all sites worked. In dev tools I have cache turned off when it's open.
Comment 44 Carlos J. Puga Medina freebsd_committer 2018-02-28 12:30:55 UTC
(In reply to bourne.identity@hotmail.com from comment #40)

From the menu it's: top-right Chromium Menu/three vertical dots (⋮) > More tools > Extensions.
Comment 45 bourne.identity@hotmail.com 2018-02-28 12:33:17 UTC
Ah yes. I see it now easily - and the last time I looked hard and failed to spot it. Thanks a lot, CPM.
Comment 46 Carlos J. Puga Medina freebsd_committer 2018-02-28 12:44:19 UTC
(In reply to Rob Belics from comment #43)

I'm not sure if it would help in your case but I'm using the OpenGL ES 2.0 SwiftShader.

Just disable the GPU hardware acceleration to use SwiftShader instead.

Comment 47 Grzegorz Junka 2018-02-28 23:00:32 UTC
For me an easy way to reproducing this issue is to go to youtube.com and keep opening new videos from recommendations in new tabs. Every few tabs opened there will be a tab that hangs loading the video. Then eventually it will die.
Comment 48 Rob Belics 2018-02-28 23:07:00 UTC
(In reply to Carlos J. Puga Medina from comment #46)

What I found throughout today was that I no longer see tabs crashing, as another bug report shows, but I do see tabs hanging. In every case, I was able to do a F5 or ctrl-F5 and the page refreshes and works like normal. This coincides with my earlier comment about having cache turned off while using dev tools.
Comment 49 Rob Belics 2018-02-28 23:09:34 UTC
If this is helpful, here is the output on my terminal:

[1091:530669568:0228/170558.730061:ERROR:gl_context_glx.cc(232)] Couldn't make context current with X drawable.
[1091:530669568:0228/170558.730099:ERROR:gpu_command_buffer_stub.cc(793)] Failed to make context current.

The same terminal is flooded with these:

[1078:547239424:0228/170754.030289:ERROR:process_metrics.cc(105)] Not implemented reached in int base::ProcessMetrics::GetIdleWakeupsPerSecond()
Comment 50 Nicola Mingotti 2018-03-03 11:33:52 UTC
I confirm some tabs hangs. It can happen in simple or complex pages.
To me it happens with approximate frequency: 1 times every 15 tabs opened.

I am running FreeBSD-11.1.
Installed chromium from package
#> pkg info | grep chrom
Comment 51 Thomas Zander freebsd_committer 2018-03-03 12:56:24 UTC
(In reply to Rob Belics from comment #49)

The messages about GetIdleWakeupsPerSecond() not being implemented should not be a problem (fingers crossed, though). Chromium continuously samples metrics of its processes. This one metric just can't be sampled on FreeBSD then. But it should not make tabs crash. For additional info on the topic, see https://bugs.chromium.org/p/chromium/issues/detail?id=120488

However, I just observed a tab crashing and the dreaded "Aw, snap!" being displayed, I noticed this one:

[43273:506440448:0303/134803.387965:ERROR:socket_stream.cc(210)] Closing stream with result -101
Comment 52 Atsushi Hasumoto 2018-03-03 13:10:15 UTC
I used FreeBSD 11.1 Release.
I found fix bug chromium browser.
My machine is nvidia graphics card.
so, upgrade nvidia driver is fix bug.
driver version is latest.
I wonder if would be helpful.
Comment 53 Carlos J. Puga Medina freebsd_committer 2018-03-10 13:52:14 UTC
I recommend to enable the "Simple Cache for HTTP" feature.

This is a new caching backend for Chrome which aims to reduce the amount of time it takes to re-validate cached files in your browser. For Windows this can add up to about 14ms per request on average, and this new caching backend aims to remove this latency. By default "Simple Cache for HTTP" is disabled, however you can enable this by pasting the flag below into Chrome.


Comment 54 Grzegorz Junka 2018-03-19 20:37:53 UTC
(In reply to Carlos J. Puga Medina from comment #53)
How is it going to help with crashing or hanging on FreeBSD?
Comment 55 Dmitri Goutnik 2018-03-19 21:36:18 UTC
(In reply to Carlos J. Puga Medina from comment #53)

This issue definitely looks to be related to caching. Mounting ~/.cache/chromium as tmpfs is what fixed "hanging tabs" issue for me.
Comment 56 timp87 2018-03-20 04:54:23 UTC
(In reply to Dmitri Goutnik from comment #55)

This WA does completely no difference to my hanging chromium at least on my home 12-CURRENT with AMD video card. Just like '"Simple Cache for HTTP" feature'.
I'll try it on 11.1-RELEASE with embedded intel card at work, but I bet it won't work too.
Comment 57 Yuri Victorovich freebsd_committer 2018-03-20 06:55:33 UTC
(In reply to timp87 from comment #56)

Using memory-fs for ~/.cache/chromium solved the problem completely for me on 11amd64, chromium-64.0.3282.186.
Comment 58 Oliver Fromme freebsd_committer 2018-03-20 15:56:02 UTC
This whole issue is obviously a race-condition in Chromium that's sensitive to timing. That's why the various pieces of advice help some people but not others. All of those advices change the timing of one part of the code or another (the cache, the renderer, the IPC, etc.), possibly causing the race-condition not to be triggered anymore, depending on various circumstances. But it does not really solve the problem, of course.

I'm afraid there's nothing FreeBSD can do about it. This needs to be fixed by the Chromium devs.
Comment 59 Yuri Victorovich freebsd_committer 2018-03-20 17:07:10 UTC
(In reply to Oliver Fromme from comment #58)

> I'm afraid there's nothing FreeBSD can do about it. This needs to be fixed by the Chromium devs.

Chrome is structured the way that they only support Windows/MacOS/Linux/Android binaries. What FreeBSD uses is Chromium, which is a free community edition, officially unsupported.

So the likelihood is that they will not fix it any time in the foreseeable future. But the latest workaround works for me (11amd64, xfce4, nvidia-driver). -) Not sure how much variability can there really be in terms of race conditions on a FreeBSD desktop.
Comment 60 Nicola Mingotti 2018-03-20 18:09:48 UTC
I ask my self, why do we call the binary "chrome" if this 
is actually "chromium" ? Also the package name is "chromium".
Comment 61 Nicola Mingotti 2018-03-20 18:17:07 UTC
To my browser "Tomo Procedure" made miracles ! 
I forwarded the wisdom to the Forum.

In run
-] FreeBSD-11.1 in a VMWare virtual machine, MacBook host, OSX 10.11.6
-] GPU disabled with "--disable-gpu"
-] 3D acceleration not available.
Comment 62 Grzegorz Junka 2018-03-20 20:57:24 UTC
(In reply to Oliver Fromme from comment #58)

Chrome works fine on Linux and Windows. What makes you think it's a problem that needs to be fixed in Chrome (by Chrome developers) and not a problem with FreeBSD-specific patches that had to be applied on top of Chrome to make it working on FreeBSD?
Comment 63 Wayne Sierke 2018-03-21 08:11:13 UTC
(In reply to Grzegorz Junka from comment #62)
I have experienced this problem on Windows, too, or at least very similar, where a tab becomes unresponsive and/or displays the Aw, snap! error. While I had originally thought that these issues might be FreeBSD-specific, I am now much less convinced.
Comment 64 Nicola Mingotti 2018-03-21 09:17:45 UTC
(In reply to Yuri Victorovich from comment #57)

Youri could you explain more in detail what you did ? 

"Tomo Method" worked well on my system but still I have
big issues with WhatsApp Web, I would like try your way.
Comment 65 Yuri Victorovich freebsd_committer 2018-03-21 09:33:44 UTC
(In reply to Nicola Mingotti from comment #64)

www/chromium/pkg-message has this explanation:
# [ -d ~{user}/.cache/chromium ] || mkdir ~{user}/.cache/chromium
# echo "md $(echo ~{user})/.cache/chromium mfs rw,late,-w{user}:{group},-s300m 2 0" >> /etc/fstab
# mount ~{user}/.cache/chromium
Comment 66 Yuri Victorovich freebsd_committer 2018-03-21 09:35:40 UTC
(In reply to Nicola Mingotti from comment #64)

It puts the cache directory on the memory disk.
Comment 67 Nicola Mingotti 2018-03-21 09:53:00 UTC
(In reply to Yuri Victorovich from comment #65)

Thank you for Yuri, in my /usr/ports/www/chromium/pkg-message  
there is only this:
For correct operation, shared memory support has to be enabled
in Chromium by performing the following command as root :

sysctl kern.ipc.shm_allow_removed=1

To preserve this setting across reboots, append the following
to /etc/sysctl.conf :


I will try later.
Comment 68 Yuri Victorovich freebsd_committer 2018-03-21 10:02:40 UTC
(In reply to Nicola Mingotti from comment #67)

You need to 'svn update'.
Comment 69 Nicola Mingotti 2018-03-21 10:22:56 UTC
(In reply to Yuri Victorovich from comment #68)
That command does not work out of the box, i get 
Skipped '/usr/ports'
svn: E155007: None of the targets are working copies
Probably some time ago, when i first got the ports,
I did it without SVN. 

I will try to move to SVN in short future.

thank you for help !
Comment 70 Oliver Fromme freebsd_committer 2018-03-21 15:12:43 UTC
(In reply to Grzegorz Junka from comment #62)
No, the same issue occurs with Chrome on Linux and Windows for some people. It's not FreeBSD-specific. There are quite a lot of threads on various websites about problems like that, just ask a search engine. And the proposed solutions are the same as for FreeBSD in this thread above: change the cache behaviour, disable GPU acceleration, update the graphics driver, reset the configuration, ...
Comment 71 Yuri Victorovich freebsd_committer 2018-03-21 18:24:58 UTC
(In reply to Oliver Fromme from comment #70)

Chrome's bug site has tens of thousands of open reports, so it's unlikely to help.

IMO, it should be reported on their subreddit: https://www.reddit.com/r/chrome/ , emphasizing that the problem occurs with Windows and Linux binaries. This might attract google's attention.
Comment 72 Thomas Zander freebsd_committer 2018-03-24 08:43:52 UTC
(In reply to Yuri Victorovich from comment #65)

The memory backed cache does not help at all. For me, the experience stays exactly the same: If the system has no load, chromium works usually fine, often for hours. As soon as I put pressure on the system (e.g. poudriere builds), this problem is triggered within seconds to minutes. The race condition hypothesis is not far-fetched at all.
Comment 73 Carlos J. Puga Medina freebsd_committer 2018-03-25 11:05:22 UTC
(In reply to Thomas Zander from comment #72)

OpenBSD was affected by this issue. They proposed the following workaround:

"Your default datasize might not be enough for v8 so if you experience the infamous "Aw, Snap!" error messages try to raise your datasize limit to a higher value.

To set it to 715M you can do the following:

$ ulimit -d 716800

or modify /etc/login.conf.

And opening lots of tabs may necessitate higher fd limits, crank that via ulimit/limits."
Comment 74 Nicola Mingotti 2018-03-26 10:25:04 UTC
(In reply to Carlos J. Puga Medina from comment #73)

Hi Carlos, I never used "ulimit" before but I guess
it will not be the solution. 

If i type "ulimit" in my system I get:

BTW, I don't see "Ah, Shap!" anymore, pages simply hangs.
Comment 75 Nicola Mingotti 2018-03-26 10:27:43 UTC
(In reply to Thomas Zander from comment #72)

I agree with you Thomas, also to me changing
to memory disk had not significant effect.
Comment 76 Nicola Mingotti 2018-03-26 10:31:06 UTC
In the first 4 hours of today Chromium was working
significantly better than usual, far less page hanging.

The only difference respect to a normal day is that today
I did not still run Google Documents. Which is usually
be default open on many (2 to 5) tabs in my browser.
Comment 77 Carlos J. Puga Medina freebsd_committer 2018-03-26 12:06:31 UTC
(In reply to Nicola Mingotti from comment #74)

Of course, it does not solve the problem but it shows that the current problem is not specific to FreeBSD.
Comment 78 Bart Ender 2018-05-30 06:54:08 UTC
(In reply to Thomas Zander from comment #72)
Confirm that. To add another wildguess, chromiums way of reading or waiting for results from its cache seems to produce the infamous 'hanging tabs', whereas a race condition somewhere is IMHO very likely.

Since I could not find a way to completely disable chromiums cache,  linking the hardcoded address ~{user}/.cache/chromium to /dev/null was an option.

After testing this for a few weeks now, I can say this actually solved the issue for me.
Comment 79 Scott Hazen Mueller 2018-06-24 01:18:54 UTC
(In reply to Rob Belics from comment #34)
There must be multiple failure modes.  I found this technique to work for hung tabs @ www.wunderground.com (which usually takes 3-5 attempts to render a single page, using this I could navigate the site freely) but facebook locked up a few clicks in as usual.

I've tried tmpfs, linking cache to /dev/null, disabling gpu, disabling v8, nothing has gotten me a stable chromium.  WU is my normal test case, now I'm in a mode where it works and FB is reasonably unreliable.

I'm running 11.1 release on an Intel Core Duo 6400 processor, 4GB of RAM (some unused because architecture), dual 250GB mirrored SSDs, an Nvidia-based graphics card (GeForce GT 610), nothing special, fairly old hardware.
Comment 80 Tomo 2018-06-29 18:44:33 UTC
The "--disk-cache-size=0" command line option was effective for me.
It improved problem of freezing during rendering(but not completely).

I'm also using following workarounds(I don't know if it's all necessary):
 * disable v8 cache(Comment #24)
 * Simple Cache for HTTP(Comment #53)
 * tmpfs(Comment #55).
Comment 81 Jan Beich freebsd_committer 2018-07-20 19:28:25 UTC
Can someone check if the patch in bug 181741 has any effect? Maybe some hangs (e.g., cache on high latency storage but not GPU driver bugs) are due to IPC.

Just a wild guess.
Comment 82 isuy 2018-07-27 08:09:47 UTC
(In reply to Yuri Victorovich from comment #65)

I keep getting Illegal Variable Name when I enter the command.

# echo "md $(echo ~{user})/.cache/chromium mfs rw,late,-w{user}:{group},-s300m 2 0" >> /etc/fstab

And of course, I replaced {user}, {group}  properly.
Comment 83 Rob Belics 2018-07-27 11:31:27 UTC
(In reply to isuy from comment #82)
I thought I was doing something wrong, and maybe I am, but I have this same issue.
Comment 84 Carlos J. Puga Medina freebsd_committer 2018-07-27 12:39:49 UTC
(In reply to isuy from comment #82)

Please, read the following message posted on freebsd-chromium ML

Comment 85 Oliver Fromme freebsd_committer 2018-07-27 12:44:06 UTC
(In reply to isuy from comment #82)
That error occurs if you use csh / tcsh. The commands from comment #65 use POSIX shell syntax and work with bash, zsh or FreeBSD's /bin/sh.
Comment 86 Rob Belics 2018-07-27 13:17:18 UTC
(In reply to Carlos J. Puga Medina from comment #84)
mount ~{joe}/.cache/chromium
mount: ~{joe}/.cache/chromium: unknown special file or file system
Comment 87 Carlos J. Puga Medina freebsd_committer 2018-07-27 13:24:26 UTC
(In reply to Rob Belics from comment #86)

Have you replace 'joe' with your username?
Comment 88 Rob Belics 2018-07-27 13:54:31 UTC
(In reply to Carlos J. Puga Medina from comment #87)
Don't ask silly questions.
Comment 89 Carlos J. Puga Medina freebsd_committer 2018-07-27 14:06:58 UTC
(In reply to Rob Belics from comment #88)

Hey, next time I will not answer your question(s)

You can do it manually.
Comment 90 Carlos J. Puga Medina freebsd_committer 2018-07-27 14:20:39 UTC
Just follow the instructions of www/chromium/pkg-message

# mkdir /home/user/.cache/chromium

Add this line to your /etc/fstab

md /home/user/.cache/chromium mfs rw,late,-wuser:group,-s300m 2 0
# mount /home/user/.cache/chromium

Run df(1) to check that /dev/md0 is already mounted.
Comment 91 Rob Belics 2018-07-27 15:05:50 UTC
(In reply to Carlos J. Puga Medina from comment #90)
Entering this manually did work. GMail tab, the first thing I opened, did seem to hang but I only waited 20 seconds. I will use chromium for the rest of the day to see how it goes.

I was running the current version all day yesterday and, while some tabs took a long time to load, they did load in less than 30 seconds though I didn't time it.
Comment 92 Rob Belics 2018-07-27 18:54:00 UTC
This failed quickly with hanging tabs just a couple of hours after trying it.
Comment 93 Sean Chittenden freebsd_committer 2018-07-28 07:05:20 UTC
Use of an md(4) FS to replace ~/.cache/chromium may have reduced the rate of hung tabs for some people, but it certainly hasn't made any material impact from my perspective.  Because of that, I wish we wouldn't call this suggestion a workaround or a fix because it's doing neither (though possibly it does improve this behavior for some).
Comment 94 timp87 2018-08-03 07:55:36 UTC
I can't any problems on chromium-67.0.3396.87 anymore.
Comment 95 Scott Hazen Mueller 2018-08-03 11:16:36 UTC
Well, I solved my own problem:  After some 25 years, I no longer run FreeBSD as a desktop.  Chrome is plenty stable on Mac.
Comment 96 Sean Chittenden freebsd_committer 2018-08-13 07:42:56 UTC
I believe this has been fixed.  There were a number of commits that markj@ made, but I believe the following was the actual culprit (thank you markj@!):


I've been using a version of -CURRENT that is 4d old (~Aug 9th 2018, 12.0-ALPHA1) and have not had any problems since upgrading my kernel to pull in these patches.

At best the mfs workarounds only reduce the likelihood of occurrence, but don't actually prevent the problem.  It would be good for someone else to confirm this so we can begin removing the incorrect suggestion in pkg-message and point people in the direction of upgrading to a version of the kernel that doesn't have this bug.
Comment 97 bkarp 2018-08-13 09:30:43 UTC
(In reply to Sean Chittenden from comment #96)

The prospect of the elimination of this bug is fantastic news--after 23 years, I was starting to reluctantly consider giving up on FreeBSD for desktop use.

If others verify that this patch fixes chromium tab hangs on 12-CURRENT, please let me register an enthusiastic request for this to be MFC'ed as soon as possible. I believe having a usable chromium on STABLE will benefit many, and is important to the perception of FreeBSD as a viable desktop platform!

(And I'm happy to test patches against 11.2-RELEASE if testers for MFC patches are needed...)

Comment 98 Mark Johnston freebsd_committer 2018-08-13 15:04:50 UTC
Thanks for the feedback.  I had set a fairly long MFC timeout period on the change but will aim to merge in the next several days instead, given the relative severity of the bug and the lack of fallout (so far).
Comment 99 Carlos J. Puga Medina freebsd_committer 2018-08-14 14:59:12 UTC
(In reply to Mark Johnston from comment #98)

Thanks for your work! I'll commit chromium update to 68.0.3440.106 including the new information in the pkg-message.
Comment 100 Carlos J. Puga Medina freebsd_committer 2018-08-14 23:54:24 UTC
*** Bug 216039 has been marked as a duplicate of this bug. ***
Comment 101 Carlos J. Puga Medina freebsd_committer 2018-08-15 00:02:22 UTC
*** Bug 204454 has been marked as a duplicate of this bug. ***
Comment 102 Carlos J. Puga Medina freebsd_committer 2018-08-15 00:02:58 UTC
*** Bug 226720 has been marked as a duplicate of this bug. ***
Comment 103 Nicola Mingotti 2018-08-15 11:24:53 UTC
Hi guys, 

I am re-trying Chromium, installed by package
pkg info | grep chrom

The tabs haging problem seems resolved in general 
so chapeaux, you found the way, thank you !  

But there remains a dark spot. Whatsapp still hangs.
In particular it hangs when I move to any channel containing
a video. I made it "Aw, Snap!" 3 times in a row in this way.

What do we do ? Do you observe the same issue ?
If so, do we open a more specific Bug isse "Chromium Whatsapp" ?

Comment 104 Oliver Fromme freebsd_committer 2018-08-15 12:04:37 UTC
(In reply to Nicola Mingotti from comment #103)
Are you running a recent version of -current that includes the fix mentioned in comment #96? If you don't, please update, or have a little patience until it is backported to stable/11 (should happen shortly, I hope).
Comment 105 Nicola Mingotti 2018-08-15 13:13:57 UTC
(In reply to Oliver Fromme from comment #104)

Hi Oliver, you are right, I apologize. 
I am running STABLE, I jumped in moved by comment n.94.

I can't change to CURRENT => I will wait.

Comment 106 commit-hook freebsd_committer 2018-08-15 22:55:36 UTC
A commit references this bug:

Author: cpm
Date: Wed Aug 15 22:54:56 UTC 2018
New revision: 477294
URL: https://svnweb.freebsd.org/changeset/ports/477294

  www/chromium: Update to 68.0.3440.106

  - Update amount of free disk space required to build chromium
  - Implement GPU access set up for FreeBSD [1]
  - Remove the incorrect sugestion in pkg-message and remove the fix-hanging-tabs.sh script because the bug of hanging tabs has been fixed in r337328 improving the chromium stability. Thanks to markj@ [2]

  PR:		230450 [1], 212812 [2]
  Reported by:	Oleh Hushchenkov <gor@clogic.com.ua>
  MFH:		2018Q3

Comment 107 commit-hook freebsd_committer 2018-08-16 06:58:02 UTC
A commit references this bug:

Author: cpm
Date: Thu Aug 16 06:57:26 UTC 2018
New revision: 477309
URL: https://svnweb.freebsd.org/changeset/ports/477309

  MFH: r477294

  www/chromium: Update to 68.0.3440.106

  - Update amount of free disk space required to build chromium
  - Implement GPU access set up for FreeBSD [1]
  - Remove the incorrect sugestion in pkg-message and remove the fix-hanging-tabs.sh script because the bug of hanging tabs has been fixed in r337328 improving the chromium stability. Thanks to markj@ [2]

  PR:		230450 [1], 212812 [2]
  Reported by:	Oleh Hushchenkov <gor@clogic.com.ua>

  Approved by:	ports-secteam (miwi)

_U  branches/2018Q3/
Comment 108 Dmitri Goutnik 2018-08-16 15:32:23 UTC
Can confirm that r337328 does indeed fix this long-standing issue. I've been running Chromium 68.0.3440.84 on 11.2-STABLE with backported r337328 and haven't experienced any tab (or extensions, which is arguably more annoying) hags/crashes so far.

Thanks to markj@ and everyone involved in bug #181741 for fixing this.
Comment 109 Rob Belics 2018-08-16 20:44:48 UTC
I beg to differ. I find tabs that still hang after surfing the web today. Using top I see about 20 processes open with three tabs sitting in GMail, Google Drive and Stack Overflow, with the SO tab being the one hanging at the moment.

This didn't occur immediately, perhaps it took a couple of hours before I noticed one hanging, but I wasn't sure if it was Chrome or the site I was visiting. But enough have happened that I do not believe the problem has gone away.

Note that I can refresh the page and everything works fine after that. In the past, refreshing was not likely to fix anything.
Comment 110 Sean Chittenden freebsd_committer 2018-08-17 02:59:32 UTC
(In reply to Rob Belics from comment #109)

@rob: Can you provide the output of your `uname(1)`, `sysctl kern.osreldate`, and the version of Chromium in use (`pkg version -n chromium`)?
Comment 111 Rob Belics 2018-08-17 11:03:27 UTC
(In reply to Sean Chittenden from comment #110)

FreeBSD rob 11.2-RELEASE-p2 FreeBSD 11.2-RELEASE-p2 #0: Tue Aug 14 21:45:40 UTC 2018     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

kern.osreldate: 1102000

chromium-68.0.3440.106             =
Comment 112 Mark Johnston freebsd_committer 2018-08-17 15:46:15 UTC
(In reply to Rob Belics from comment #111)
As noted earlier, the fix hasn't been ported to the 11.x branch yet.  I plan to do that later today, so 11-STABLE users will get the fix soon.  I'll see about having the change shipped as an errata fix for 11.2.
Comment 113 commit-hook freebsd_committer 2018-08-17 16:05:00 UTC
A commit references this bug:

Author: markj
Date: Fri Aug 17 16:04:21 UTC 2018
New revision: 337975
URL: https://svnweb.freebsd.org/changeset/base/337975

  MFC r337328:
  Don't check rcv sockbuf limits when sending on a unix stream socket.

  PR:	181741, 212812

_U  stable/11/
Comment 114 Alexander Zagrebin 2018-08-19 12:33:32 UTC
While there is no patch for releng/11.2, I have tried `sysctl net.local.stream.recvspace=16384`.
It seems the tab hanging issue has gone.
Comment 115 Nicola Mingotti 2018-08-24 15:15:17 UTC
(In reply to Alexander Zagrebin from comment #114)

I am under FreeBSD 11.1, installed via chromium-68.0.3440.106_1 
via pkg. 

I tested for two days, your methods works, no hangs.
Comment 116 Rob Belics 2018-09-03 21:19:18 UTC
(In reply to Alexander Zagrebin from comment #114)
 Ditto. This works for me, too.
Comment 117 Carlos J. Puga Medina freebsd_committer 2018-11-04 14:21:46 UTC
It was time to close this PR :)

Thanks to all who have contributed to making it possible!