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.
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).
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?
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?
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 chromium-54.0.2840.50 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: libgtk-x11-2.0.so.0 libexpat.so.1 libXext.so.6 libxslt.so.1 libpango-1.0.so.0 libjpeg.so.8 libfreetype.so.6 libFLAC.so.8 libcairo.so.2 libxml2.so.2 libXtst.so.6 libwebp.so.6 libatk-1.0.so.0 libcups.so.2 libgmodule-2.0.so.0 libXcomposite.so.1 libXss.so.1 libgdk_pixbuf-2.0.so.0 libgio-2.0.so.0 libXfixes.so.3 libwebpdemux.so.2 libnss3.so libnssutil3.so libnspr4.so libgobject-2.0.so.0 libgconf-2.so.4 libharfbuzz.so.0 libglib-2.0.so.0 libX11.so.6 libdbus-1.so.3 libXdamage.so.1 libXrender.so.1 libgdk-x11-2.0.so.0 libXcursor.so.1 libXrandr.so.2 libsnappy.so.1 libfontconfig.so.1 libsmime3.so libXi.so.6 libpangocairo-1.0.so.0 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.
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.
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. -Brad
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.
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.
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..
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 ?? ()
confirm thi
There is similar bug report https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211036
I'm getting such behaviour quiet often even on chromium-54.0.2840.100 .config/chromium was deleted 10 minutes ago.
Hangs confirmed in chromium-55.0.2883.87 (11.0-RELEASE)
confirm +1 chromium-55.0.2883.87 FreeBSD 12.0-CURRENT amd64
confirmed in chromium-56.0.2924.87 FreeBSD 12.0-CURRENT amd64 (of course with rm -rf ~/.config/chromium ~/.cache/chromium)
Still happens with chromium-56.0.2924.87, 11-STABLE/amd64 It's easy enough to reproduce when loading Facebook.
12-current, chromium 56.0.2924.87 Chromium has no problems on system which was tuned for pgsql testload. kern.ipc.shmseg=1024 kern.ipc.shmmni=1024 kern.ipc.semmns=1024 kern.ipc.semmni=128 Sometimes page may freeze but may be closed w/o kill, as usual, with mouse-click :)
(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
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).
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 chromium-55.0.2883.87 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
(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.
(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.
I use: 11-stable/amd64(r314381) 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
Woohoo, thanks a thousand times, tomo! Works for me(TM)
(In reply to Tomo from comment #24) I'm really impressed. This even made by Chromium much faster!
(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
(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.
Even with changes from Tomo, the tabs still end up hanging occasionally.
I'm comfirm. I use FreeBSD 11.0p10. I imform Chromium --debug infomation. the other site is linux(arch) infomation. https://archlinuxarm.org/forum/viewtopic.php?f=15&t=11642# 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.
I'll second what Domagoj said, this is still happening, although in my case it's way more than 10% of occasions.
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.
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!
(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.
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.
Unfortunately, chromium is now almost totally unusable with 63.0.3239.132 version :(
(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) kern.maxfiles=200000 Other relevant variables that I have changed /boot/loader.conf # Boot-time kernel tuning kern.ipc.shmseg=1024 kern.ipc.shmmni=1024 kern.maxproc=100000 /etc/sysctl.conf # Maximal (lowest) priority for preemption # give more responsiveness on desktop kern.sched.preempt_thresh=224
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?
(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.
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.
(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. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html
(In reply to Carlos J. Puga Medina from comment #41) Sure. In my workload it hardly matters.
(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.
(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.
Ah yes. I see it now easily - and the last time I looked hard and failed to spot it. Thanks a lot, CPM.
(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. https://blog.chromium.org/2016/06/universal-rendering-with-swiftshader.html
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.
(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.
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()
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 chromium-61.0.3163.100_5
(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
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.
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. chrome://flags/#enable-simple-cache-backend http://www.chromium.org/developers/design-documents/network-stack/disk-cache/very-simple-backend http://www.chromium.org/developers/design-documents/network-stack/disk-cache/disk-cache-benchmarking
(In reply to Carlos J. Puga Medina from comment #53) How is it going to help with crashing or hanging on FreeBSD?
(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.
(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.
(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.
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.
(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.
I ask my self, why do we call the binary "chrome" if this is actually "chromium" ? Also the package name is "chromium".
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.
(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?
(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.
(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.
(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
(In reply to Nicola Mingotti from comment #64) It puts the cache directory on the memory disk.
(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 : kern.ipc.shm_allow_removed=1 ------------------------- I will try later.
(In reply to Nicola Mingotti from comment #67) You need to 'svn update'.
(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 !
(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, ...
(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.
(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.
(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."
(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: "unlimited" BTW, I don't see "Ah, Shap!" anymore, pages simply hangs.
(In reply to Thomas Zander from comment #72) I agree with you Thomas, also to me changing to memory disk had not significant effect.
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.
(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.
(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.
(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.
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).
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.
(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.
(In reply to isuy from comment #82) I thought I was doing something wrong, and maybe I am, but I have this same issue.
(In reply to isuy from comment #82) Please, read the following message posted on freebsd-chromium ML https://lists.freebsd.org/pipermail/freebsd-chromium/2018-July/003608.html
(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.
(In reply to Carlos J. Puga Medina from comment #84) mount ~{joe}/.cache/chromium mount: ~{joe}/.cache/chromium: unknown special file or file system
(In reply to Rob Belics from comment #86) Have you replace 'joe' with your username?
(In reply to Carlos J. Puga Medina from comment #87) Don't ask silly questions.
(In reply to Rob Belics from comment #88) Hey, next time I will not answer your question(s) You can do it manually.
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.
(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.
This failed quickly with hanging tabs just a couple of hours after trying it.
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).
I can't any problems on chromium-67.0.3396.87 anymore.
Well, I solved my own problem: After some 25 years, I no longer run FreeBSD as a desktop. Chrome is plenty stable on Mac.
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@!): https://reviews.freebsd.org/D16515 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.
(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...) Thanks, Brad
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).
(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.
*** Bug 216039 has been marked as a duplicate of this bug. ***
*** Bug 204454 has been marked as a duplicate of this bug. ***
*** Bug 226720 has been marked as a duplicate of this bug. ***
Hi guys, I am re-trying Chromium, installed by package ----- pkg info | grep chrom chromium-67.0.3396.87 ----- 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" ? Bye Nicola
(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).
(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. bye n.
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 Log: 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 Changes: head/www/chromium/Makefile head/www/chromium/distinfo head/www/chromium/files/fix-hanging-tabs.sh head/www/chromium/files/patch-build_linux_unbundle_libwebp.gn head/www/chromium/files/patch-gpu_config_gpu__info__collector__freebsd.cc head/www/chromium/files/patch-services_network_public_cpp_cors_cors_legacy.cc head/www/chromium/files/patch-services_network_public_cpp_cors_cors_legacy.h head/www/chromium/files/patch-third_party_blink_renderer_platform_image-decoders_jpeg_jpeg_image_decoder.cc head/www/chromium/files/patch-third_party_blink_renderer_platform_image-encoders_image_encoder.cc head/www/chromium/files/patch-third_party_blink_renderer_platform_image-encoders_image_encoder.h head/www/chromium/files/patch-third_party_blink_renderer_platform_wtf_compiler.h head/www/chromium/files/pkg-message.in head/www/chromium/pkg-plist
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 Log: 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) Changes: _U branches/2018Q3/ branches/2018Q3/www/chromium/Makefile branches/2018Q3/www/chromium/distinfo branches/2018Q3/www/chromium/files/fix-hanging-tabs.sh branches/2018Q3/www/chromium/files/patch-build_linux_unbundle_libwebp.gn branches/2018Q3/www/chromium/files/patch-gpu_config_gpu__info__collector__freebsd.cc branches/2018Q3/www/chromium/files/patch-services_network_public_cpp_cors_cors_legacy.cc branches/2018Q3/www/chromium/files/patch-services_network_public_cpp_cors_cors_legacy.h branches/2018Q3/www/chromium/files/patch-third_party_blink_renderer_platform_image-decoders_jpeg_jpeg_image_decoder.cc branches/2018Q3/www/chromium/files/patch-third_party_blink_renderer_platform_image-encoders_image_encoder.cc branches/2018Q3/www/chromium/files/patch-third_party_blink_renderer_platform_image-encoders_image_encoder.h branches/2018Q3/www/chromium/files/patch-third_party_blink_renderer_platform_wtf_compiler.h branches/2018Q3/www/chromium/files/pkg-message.in branches/2018Q3/www/chromium/pkg-plist
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.
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.
(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`)?
(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 =
(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.
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 Log: MFC r337328: Don't check rcv sockbuf limits when sending on a unix stream socket. PR: 181741, 212812 Changes: _U stable/11/ stable/11/sys/kern/uipc_sockbuf.c stable/11/sys/kern/uipc_usrreq.c stable/11/sys/sys/sockbuf.h
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.
(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.
(In reply to Alexander Zagrebin from comment #114) Ditto. This works for me, too.
It was time to close this PR :) Thanks to all who have contributed to making it possible!
Not sure why this PR was closed, hangs still happen on latest builds: FreeBSD 11.2-RELEASE-p7 chromium-68.0.3440.106_7 I've tried `sysctl net.local.stream.recvspace=16384` suggested above, so far works good.
(In reply to robert.ayrapetyan from comment #118) The fix is in stable/11, but not in releng/11.2, as far as I can see. If you need to have the fix, I suggest updating to 12.0.
I still have problems with Chromium hanging in 12.0. FreeBSD 12.0-RELEASE-p3 GENERIC amd64 Chromium from pkg, Version 72.0.3626.121 (Official Build) (64-bit)
(In reply to jimbo from comment #120) Is there any reason to think that your problem is related? Do any of the workarounds listed here help? If not, a separate PR is warranted. If possible, try to find a scenario which triggers the hang so that others can try and reproduce it.