New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 34 users
Status: Fixed
Owner:
Closed: Apr 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Compat



Sign in to add a comment
Tab freezes in Chrome 34 in WebGL/Web Worker app
Reported by paraq...@gmail.com, Apr 9 2014 Back to list
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36

Example URL:
http://cesiumjs.org/chrome_hang/HelloWorld.html

Steps to reproduce the problem:
1. Visit http://cesiumjs.org/chrome_hang/HelloWorld.html  
2. Refresh a few times until the page only shows a blue-white atmosphere ring with no globe.
3. All UI input is blocked, dev tools unresponsive.
4. Eventually the Page Unresponsive popup appears.

What is the expected behavior?
In Chrome 33 this worked.  Firefox 28 also OK.

What went wrong?
This hang seems timing-dependent and doesn't always occur, which is why it may take a few refreshes.  

I don't know if this is the same issue as  https://code.google.com/p/chromium/issues/detail?id=361618 or not, but that bug is also tracking a WebGL-related regression in 34.

This application creates several web workers on startup.  One of the web workers calls worker.terminate from inside its onmessage callback to shut down the worker when done.  I was able to reduce the frequency of the hangs, but not completely eliminate them, by removing that call to terminate.  I don't know if that indicates a web worker problem, or whether it merely changes the timing around.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? Yes Chrome 33

Does this work in other browsers? Yes 

Chrome version: 34.0.1847.116  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 13.0 r0
 
Comment 1 by paraq...@gmail.com, Apr 9 2014
I checked and the hang also occurs on OS X 10.7.5 in Chrome 34, so I guess it's not ANGLE-related like the issue I linked above.
Comment 2 Deleted
Comment 3 Deleted
While I can reproduce this easily with 34.0.1847.116 (Windows 8.1), I can't reproduce it at all in canary 36.0.1932.2.  DX9 back-end in both cases.
Comment 5 by tsta...@gmail.com, Apr 10 2014
I can confirm that version 34 hangs, while the dev version (35) works fine. This is both on the example posted and on my own application.
I may have found another exhibit of this issue. 

To reproduce the problem visit this demo (either for the first time ever with Chrome 34, or with completely clean cache, or in private browsing mode):

http://alteredqualia.com/xg/examples/animation_physics_level.html

For me it freezes near the end of initialization, before ground textures appear. Subsequent reloads are then fine, no more freezes.

I do use web workers when creating the content. 

At first I was suspecting this was Chrome 34 ANGLE shader compilation issue like in #361618, but this issue made me re-check - I do get freezes both with DX9 and DX11 ANGLE. It does work ok in Chrome Canary 36.0.1932.2 and it did work ok in stable Chrome 33.
And here is another WebGL site that freezes upon first load:

http://www.findyourwaytooz.com/
Cc: tkonch...@chromium.org
Labels: Cr-Blink-WebGL M-34
Status: Untriaged
Able to repro the issue on win8 chrome version 34.0.1847.116 (Official Build 260972) but this is working fine in latest 36.0.1933.0 (Official Build 262849) canary

@paraquat, Could you please check this issue in latest chrome version and update the thread. 

Please let us know if further bisect info is needed on the same.
Comment 9 by paraq...@gmail.com, Apr 10 2014
Yes, I checked and it's working in 36.0.1933.0 canary.
Comment 10 by k...@lagoa.com, Apr 10 2014
Could this be related to the following security fix?

[343661] High CVE-2014-1719: Use-after-free in web workers
Comment 11 by kbr@chromium.org, Apr 10 2014
Cc: kbr@chromium.org shannonwoods@chromium.org geoffl...@chromium.org jmad...@chromium.org capn@chromium.org zmo@chromium.org bajones@chromium.org
Labels: Cr-Blink-Workers Cr-Internals-GPU-ANGLE
Comment 12 by tsta...@gmail.com, Apr 10 2014
Could be related -- seems like preventing garbage collection of the web workers (by keeping them referenced) makes the hang go away.
Comment 13 by rhu...@gmail.com, Apr 10 2014
This matches our experience with our OpenCar SDK web application (http://sdk.opencar.com/). Version 34 hangs  while previous versions and 35/36 work fine. 
Comment 14 by zmo@chromium.org, Apr 10 2014
Labels: Merge-Requested
Confirmed.  https://codereview.chromium.org/212553002 fixes this deadlock.

This is a simple and safe fix, and I feel we should merge back to M34.
Comment 15 by zmo@chromium.org, Apr 11 2014
Owner: ager@chromium.org
Status: Assigned
Comment 16 by ager@chromium.org, Apr 11 2014
Status: Started
I agree, we should definitely merge that back to M34.
Comment 17 by ager@chromium.org, Apr 11 2014
Cc: ager@chromium.org
Owner: haraken@chromium.org
I'm going on vacation today for a week. Setting Haraken as the owner so we can get this merge in as soon as the merge request is approved.
Comment 18 by t...@lagoa.com, Apr 11 2014
This issue has caused quite a lot of disruption with the lagoa.com service.  We've found a work-around on our side, but we'd like to know the time-frame for getting the fix [#14] into the wild.  

Will it be pushed as an emergency patch?  When will the next stability update be pushed for M34?
Comment 19 by kbr@chromium.org, Apr 11 2014
Cc: dxie@chromium.org vangelis@chromium.org
Labels: -Pri-2 Pri-1
I'm raising this to P1 and CC'ing one of the PMs.

David, I am requesting this patch be merged back to M34. Web Workers were completely broken in this release, and this fact has broken real-world applications. We need to understand why there was such a gap in testing, but in the meantime it's essential to fix these applications immediately.

Comment 20 by jmor...@jive.com, Apr 11 2014
Just wanted to say that I see this behavior with web workers and not WebGL. I believe it is entirely related to web workers. I saw this at some point in Canary when Canary was 34 and assumed it was just an issue with me messing around with my Canary set up. Next time I'll file a bug.

I'd really love to get this fixed ASAP as well. Is there any workaround that solves this issue that I can do in my JS?
Comment 21 by t...@lagoa.com, Apr 11 2014
On the JS side, we found that converting from dynamic construction of web-worker instances to a static web-worker pool prevented the hang.  We construct all worker instances that will be required, and reuse the same workers to service multiple job requests, while never closing any of the worker processes.

This approach prevented the deadlock/hang for us.
Labels: ReleaseBlock-Stable
Adding RLS and alerting dxie@
Hi, it prevents a major release of a product for us as well. This is a truly bad regression. I would like to see a path as well.

We also found a workaround but it has many problems including memory leaks and performance proble,s
Comment 24 by rhu...@gmail.com, Apr 14 2014
Is there any date estimate for the M34 update? We also have a product release on hold now.

Tags may not show proper severity; they should be: 
Type Bug-Regression 
OS All (confirmed on Mac and Linux also)
Cr Blink-Workers (only)
...and remove WebGL from the title. 
Cc: kareng@google.com
Given the severity, I'd like to merge the CL as soon as possible. Would you approve the merge request?

Comment 26 by kareng@google.com, Apr 14 2014
m34 is for dxie to approve.
Comment 27 by Deleted ...@, Apr 14 2014
Our application has completely stopped  working because of this issue and production deployments are on hold now. Would you please let us know by when the patch will be avaialable in version 34?
I dont' see dxie on the notification list - can someone add dxie?
dxie is already cc-ed. I'll send him a direct email.
Comment 30 by dxie@google.com, Apr 14 2014
Labels: -Merge-Requested Merge-Approved
approved for M34.
Comment 32 by kbr@chromium.org, Apr 14 2014
zmo@: thank you for so quickly tracking down the cause of this regression.

Agree - thank you for fast tracking this!
Merged r170047 to M34.

When will this patch be available to the public for update?
Comment 36 by dxie@chromium.org, Apr 15 2014
Status: Fixed
Moving this to fixed.  
Comment 37 by jmor...@jive.com, Apr 17 2014
Does that mean that this is fixed and has been released to the general public?
Our Application makes extensive use of dedicated and shared workers. I have "Chrome 34.0.1847.116 m" installed on my machine.
With this chrome version, I can still observe the Chrome being unresponsive ("not responding/hang") even for  SINGLE TAB.
The forum also says that this issue has been MERGED. If this is the case, then can you conform, WHICH build or VERSION of chrome, has the FIX for this issue ?
Also, if this issue is NOT been pushed for Updates, when is it expected to release for Production. 
Thanks !
We had the same issue
For those who would be interested. I tried to use SharedWorker instead of the Worker object, and it works!
For SharedWorker implementation see:
    http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#shared-workers-introduction

However SharedWorker is not supported under Firefox and IE 11 but it's supported under Safari.
WRT comment #39
https://bugzilla.mozilla.org/show_bug.cgi?id=643325  (implemented 2013-10-03)
https://bugzilla.mozilla.org/show_bug.cgi?id=924089  (enabled by default 2013-12-11)

Looks like it is in the Firefox 29 beta, so will be released in 5 days.

An aside. I really really hate the fact that code.google.com sets background-color on buttons, but not color, so I get white text on a white background, and have to be careful I don't discard my comments by mistake.

Comment 41 by paraq...@gmail.com, Apr 25 2014
This is fixed in Version 34.0.1847.131 m, released yesterday.

Comment 42 by gman...@gmail.com, Apr 26 2014
Nope it isn't: installed the update & chrome still freezes...
"34.0.1847.131 m" fixed our issue with the Worker deadlock, and it does fix the issue of the original post of the current bug report:
http://cesiumjs.org/chrome_hang/HelloWorld.html
Comment 44 by laforge@google.com, May 15 2015
Labels: -Merge-Approved
Sign in to add a comment