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

Issue metadata

Status: Fixed
Closed: Apr 2014
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Compat

Sign in to add a comment

Issue 361792: Tab freezes in Chrome 34 in WebGL/Web Worker app

Reported by, Apr 9 2014

Issue description

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:

Steps to reproduce the problem:
1. Visit  
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 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, 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

Comment 4 by, Apr 9 2014

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, 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.

Comment 6 by, Apr 10 2014

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):

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.

Comment 7 by, Apr 10 2014

And here is another WebGL site that freezes upon first load:

Comment 8 by, Apr 10 2014

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, Apr 10 2014

Yes, I checked and it's working in 36.0.1933.0 canary.

Comment 10 by, 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, Apr 10 2014

Labels: Cr-Blink-Workers Cr-Internals-GPU-ANGLE

Comment 12 by, 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, Apr 10 2014

This matches our experience with our OpenCar SDK web application ( Version 34 hangs  while previous versions and 35/36 work fine.

Comment 14 by, Apr 10 2014

Labels: Merge-Requested
Confirmed. fixes this deadlock.

This is a simple and safe fix, and I feel we should merge back to M34.

Comment 15 by, Apr 11 2014

Status: Assigned

Comment 16 by, Apr 11 2014

Status: Started
I agree, we should definitely merge that back to M34.

Comment 17 by, Apr 11 2014

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, Apr 11 2014

This issue has caused quite a lot of disruption with the 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, Apr 11 2014

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, 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, 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.

Comment 22 by, Apr 11 2014

Labels: ReleaseBlock-Stable
Adding RLS and alerting dxie@

Comment 23 by, Apr 12 2014

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, 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.

Comment 25 by, Apr 14 2014

Given the severity, I'd like to merge the CL as soon as possible. Would you approve the merge request?

Comment 26 by, 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?

Comment 28 by, Apr 14 2014

I dont' see dxie on the notification list - can someone add dxie?

Comment 29 by, Apr 14 2014

dxie is already cc-ed. I'll send him a direct email.

Comment 30 by, Apr 14 2014

Labels: -Merge-Requested Merge-Approved
approved for M34.

Comment 32 by, Apr 14 2014

zmo@: thank you for so quickly tracking down the cause of this regression.

Comment 33 by, Apr 15 2014

Agree - thank you for fast tracking this!

Comment 34 by, Apr 15 2014

Merged r170047 to M34.

Comment 35 by, Apr 15 2014

When will this patch be available to the public for update?

Comment 36 by, Apr 15 2014

Status: Fixed
Moving this to fixed.

Comment 37 by, Apr 17 2014

Does that mean that this is fixed and has been released to the general public?

Comment 38 by, Apr 21 2014

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 !

Comment 39 by, Apr 23 2014

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:

However SharedWorker is not supported under Firefox and IE 11 but it's supported under Safari.

Comment 40 by, Apr 24 2014

WRT comment #39  (implemented 2013-10-03)  (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 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, Apr 25 2014

This is fixed in Version 34.0.1847.131 m, released yesterday.

Comment 42 by, Apr 26 2014

Nope it isn't: installed the update & chrome still freezes...

Comment 43 by, Apr 26 2014

"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:

Comment 44 by, May 15 2015

Labels: -Merge-Approved

Sign in to add a comment