Last Comment Bug 598166 - Google Blob demo hangs system when moving window
: Google Blob demo hangs system when moving window
Status: RESOLVED DUPLICATE of bug 575515
:
Product: Core
Classification: Components
Component: Canvas: WebGL (show other bugs)
: Trunk
: x86_64 Windows 7
: -- major with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://code.google.com/p/webglsamples/
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-20 15:23 PDT by Gary [:streetwolf]
Modified: 2010-10-12 12:59 PDT (History)
17 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
MSVC dump without heap (299.31 KB, application/octet-stream)
2010-09-20 18:26 PDT, Benoit Jacob [:bjacob] (mostly away)
no flags Details
Windbg log (50.51 KB, text/plain)
2010-09-22 03:52 PDT, Scoobidiver (away)
no flags Details
Test case, self-contained, only gl.clear() and gl.finish() (5.71 KB, text/html)
2010-09-22 07:37 PDT, Benoit Jacob [:bjacob] (mostly away)
no flags Details
minimal test case, without fps-counter element, without fillrate hogging (4.63 KB, text/html)
2010-09-22 07:59 PDT, Benoit Jacob [:bjacob] (mostly away)
no flags Details
LOL-minimal test case --- no canvas anymore, just a JS loop (565 bytes, text/html)
2010-09-22 08:29 PDT, Benoit Jacob [:bjacob] (mostly away)
no flags Details

Description Gary [:streetwolf] 2010-09-20 15:23:14 PDT
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100920 Firefox/4.0b7pre
Build Identifier: 20100920123427

Go to the URL given. Click on the second demo, Blob. When it's running either resize the window or move it. My system freezes on me. Getting into Task Manager using Ctrl-Alt-Del get's things going again so you can exit Fx. I'm on W7 x64.

HW acceleration is on.

Reproducible: Always
Comment 1 Myzar 2010-09-20 15:35:47 PDT
i see the same pasting a quick link to the case http://webglsamples.googlecode.com/hg/blob/blob.html

just moving the window will freeze the browser until you push Ctrl-Alt-Del that will revive it
Comment 2 Myzar 2010-09-20 15:40:16 PDT
http://webglsamples.googlecode.com/hg/caves/caves.html

doesn't display anything
Comment 3 Csaba Kozák [:WonderCsabo] 2010-09-20 15:43:47 PDT
Confirmed on fresh profile, Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100920 Firefox/4.0b7pre.latest hourly: http://hg.mozilla.org/mozilla-central/rev/573b9178b897Disabling JM or TM or D2D or layers or both wont resolve the problem.
Comment 4 Gary [:streetwolf] 2010-09-20 16:03:28 PDT
(In reply to comment #2)
> http://webglsamples.googlecode.com/hg/caves/caves.html
> 
> doesn't display anything

Actually I got it working once  a little while ago. Hung up but not Fx or the system.  Now all I get is a red box where the Caves should be.
Comment 5 Csaba Kozák [:WonderCsabo] 2010-09-20 16:11:43 PDT
Maybe you should CC Boris and Benoit from Bug 596544 .
Comment 6 Benoit Jacob [:bjacob] (mostly away) 2010-09-20 17:43:50 PDT
(In reply to comment #2)
> http://webglsamples.googlecode.com/hg/caves/caves.html
> 
> doesn't display anything

We've discussed the Caves demo on the public webgl list, with the author. It seems to have a race condition preventing it to load correctly. But if you refresh a couple of times, and are lucky, it will show up properly. Anyway, not our bug (only working "by accident" in Chrome) as far as we can see.
Comment 7 Benoit Jacob [:bjacob] (mostly away) 2010-09-20 17:45:43 PDT
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre)
> Gecko/20100920 Firefox/4.0b7pre
> Build Identifier: 20100920123427
> 
> Go to the URL given. Click on the second demo, Blob. When it's running either
> resize the window or move it. My system freezes on me. Getting into Task
> Manager using Ctrl-Alt-Del get's things going again so you can exit Fx. I'm on
> W7 x64.
> 
> HW acceleration is on.
> 
> Reproducible: Always

Hm, can't reproduce under linux with GL layers.

Rebooting in windows to check...
Comment 8 Benoit Jacob [:bjacob] (mostly away) 2010-09-20 18:26:59 PDT
Created attachment 476992 [details]
MSVC dump without heap

OK, it's easy indeed to reproduce on Windows.

What was harder was to be able to get to the MSVC UI to debug into it... here's a dump. It shows thread waiting or polling. So it's looking like a deadlock. I can't see much relevant from a WebGL / graphics point of view.

Sometimes it unfreezes on its own after a while.
Comment 9 Benoit Jacob [:bjacob] (mostly away) 2010-09-20 18:36:30 PDT
Confirming that the hang happens only with 64 bit Firefox.

Because of that, it won't be handled in priority (we don't aim to support 64 bit Firefox builds under Windows officially in 4.0. But we do support running 32 bit builds under Win64).
Comment 10 Gary [:streetwolf] 2010-09-20 18:53:16 PDT
I'm running 32 bit Fx4 on Windows 7 x64.
Comment 11 Benoit Jacob [:bjacob] (mostly away) 2010-09-20 18:57:15 PDT
Ah!

Then this is suddenly much more critical!

Let's see if the Graphics people have something to say about it.
Comment 12 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-09-20 19:29:19 PDT
This certainly sounds confirmed.
Comment 13 Bas Schouten (:bas.schouten) 2010-09-20 20:05:38 PDT
D2D/D3D9 on/off make no difference here, symptoms are always the same. Interestingly it resumed rendering just fine if you alt+tab away and then back in. I haven't done much diagnostic work yet so I've got no idea what's causing it.
Comment 14 Exactly {Clear} 2010-09-20 21:20:28 PDT
it works fine for me on chrome canary. but on firefox, for somereason i get the following message : 
This page requires a browser that supports WebGL.
Click here to upgrade your browser.
is WebGL turnd off on intel gfx ?
Comment 15 Csaba Kozák [:WonderCsabo] 2010-09-20 22:49:34 PDT
I'm running a 32 bit Firefox on 64 bit Windows, and have the problem. As I mentioned in comment 3, disabling JM or TM or D2D or layers or both wont resolve the problem.

It also freezes when you resize the window. Not when you use maximize, etc buttons, but when you drag the window's borders to resize. Gary should rename the bug to add this.
Comment 16 Benoit Jacob [:bjacob] (mostly away) 2010-09-21 03:43:50 PDT
(In reply to comment #14)
> it works fine for me on chrome canary. but on firefox, for somereason i get the
> following message : 
> This page requires a browser that supports WebGL.
> Click here to upgrade your browser.
> is WebGL turnd off on intel gfx ?

It was until yesterday, so the latest nightly should allow you to do WebGL. But be advised that due to **** openGL drivers on windows, intel gfx are potentially buggy there. In Chrome, they use Direct3D via ANGLE for that, and that's what we're going to do too, soonish.
Comment 17 Scoobidiver (away) 2010-09-21 04:07:15 PDT
I am running FF 32-bit on Win 7 64-bit with Intel gfx :
I have the same problem.
Setting layers.shader_validator to false solves the problem.
I think it is a dupe of bug 594387.
Comment 18 Benoit Jacob [:bjacob] (mostly away) 2010-09-21 04:22:29 PDT
(In reply to comment #17)
> Setting layers.shader_validator to false solves the problem.


OOOh. Great catch !!
Comment 19 Benoit Jacob [:bjacob] (mostly away) 2010-09-21 04:26:53 PDT
OK, not sure yet if it's a dupe of bug 594387. But both are definitely going to be ANGLE issues. It could be worth checking if bugs have been fixed in ANGLE lately and updating. It could also be worth making ANGLE bug reports but for that we need to narrow it down to the particular shader that's causing issues. We also need to figure if the problem is in ANGLE itself or in the way we're using it.
Comment 20 Csaba Kozák [:WonderCsabo] 2010-09-21 04:28:11 PDT
What problem?

If i set that key to false, (and restart Minefield to set the changes) the Blob demo still hangs the system when i resize or move the window.

And it generates massive memory consumption (230MB), but i think that's another bug.
Comment 21 Scoobidiver (away) 2010-09-21 06:25:31 PDT
Comment 17 was wrong. After a new try, I can reproduce the issue with layers.shader_validator to false.

Other causes of hang with this demo :
* resizing of FF window 
* moving of Error console window
Comment 22 Csaba Kozák [:WonderCsabo] 2010-09-21 06:31:15 PDT
Correct, you have exactly the same issue as me.

Disabling JM or TM or D2D or layers or both dont resolve the problem.
Comment 23 Scoobidiver (away) 2010-09-22 03:51:18 PDT
I added a Windbg log. But I don't think it is useful, because when system hang, going back to Windbg window requires a ALT+TAB key that stops hang.
Comment 24 Scoobidiver (away) 2010-09-22 03:52:19 PDT
Created attachment 477459 [details]
Windbg log
Comment 25 Benoit Jacob [:bjacob] (mostly away) 2010-09-22 04:53:32 PDT
So, I have news.

Using the verbose debug mode from Bug 597881, I realized that while it is "frozen", it is actually continuing issuing lots and lots of GL calls.

So my best guess is that Windows' own compositing engine (which is stressed when we move the window around), which is using shaders too, is not playing well with shader-intensive OpenGL code. In this case, the explanation why Chrome is not affected would be that they use Direct3D for rendering on Windows, as we soon will (looks like we don't have a choice).
Comment 26 Csaba Kozák [:WonderCsabo] 2010-09-22 04:57:22 PDT
It means that D3D rendering via ANGLE for WebGL will block 4.0 final?
Comment 27 Benoit Jacob [:bjacob] (mostly away) 2010-09-22 05:09:54 PDT
Switching to Windows Classic theme seems to make it a bit better, but I can still reproduce the problem (trying a bit longer). But it seems to me that Windows Classic is still composited, e.g. how else could it render the blue shade when about to maximize a window.
Comment 28 Benoit Jacob [:bjacob] (mostly away) 2010-09-22 05:10:48 PDT
(In reply to comment #26)
> It means that D3D rendering via ANGLE for WebGL will block 4.0 final?

It means that it's becoming a bigger priority than expected. I need to discuss this with other people.
Comment 29 Benoit Jacob [:bjacob] (mostly away) 2010-09-22 07:37:49 PDT
Created attachment 477497 [details]
Test case, self-contained, only gl.clear() and gl.finish()

Here's a small self-contained test case!

All it does is repeatedly call gl.clear() and gl.finish() a thousand times per render() call. And render() is called by a setInterval with 1 ms interval. So it's just hogging the GPU's fillrate.

When I move the firefox window, Windows 7 freezes and locks the mouse pointer so I can't get to the taskbar. Pressing Ctrl+Alt+Delete restores normal operation.
Comment 30 Benoit Jacob [:bjacob] (mostly away) 2010-09-22 07:41:24 PDT
Time to ask what graphics card is everybody using?

I have a NVIDIA quadro FX 880M.

Scoobidiver do you confirm that it's on a Intel card that you can reproduce the problem?

2 different vendors would rule out a driver issue...
Comment 31 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-09-22 07:54:30 PDT
> setInterval with 1 ms interval.

So a 10ms interval, due to the clamping.  Just in case it matters.
Comment 32 Benoit Jacob [:bjacob] (mostly away) 2010-09-22 07:59:32 PDT
Created attachment 477500 [details]
minimal test case, without fps-counter element, without fillrate hogging

Here's a better testcase:
 - not calling clear/finish 1000 times per render() anymore. Just calling it once, but instead we do a very expensive JS loop. So we don't hog the GPU anymoe, we hog the CPU (in Firefox's process).
 - not using a "FPS counter" HTML element anymore. Now there is only a webgl canvas in this page, nothing else.

Also, setting setInterval to 10 ms :-) it didn't matter.
Comment 33 Scoobidiver (away) 2010-09-22 08:07:33 PDT
> Scoobidiver do you confirm that it's on a Intel card that you can reproduce the
> problem?
Yes, Intel GMA 4500MHD, graphic driver : 8.15.10.2202
> Here's a better testcase:
With the minimal testcase, I can reproduce the system hang when I move the FF window.
Comment 34 Benoit Jacob [:bjacob] (mostly away) 2010-09-22 08:29:03 PDT
Created attachment 477509 [details]
LOL-minimal test case --- no canvas anymore, just a JS loop

Actually this whole bug has nothing to do with Canvas / WebGL / OpenGL / whatever !!

Look at this new testcase, all it does is set up a setInterval timer that runs a big JS loop everytime it ticks.

Load this page, then move your window around, it should freeze Windows in the sense that it won't respond to your clicks, and will also constrain your mouse pointer above the taskbar; exit by pressing Ctrl+Alt+Del.

How should this bug be retagged now? It's clearly a Windows bug that an app may freeze it just by being a CPU hog, but I guess that we could do something to work around it... is it the case that Windows expects apps to respond to "messages" or "events" when their main window is being moved??
Comment 35 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-09-22 08:35:22 PDT
> is it the case that Windows expects apps to respond to
> "messages" or "events" when their main window is being moved??

Or resized, iirc...

ccing some folks who might know something about the Windows move/resize event loop.
Comment 36 Timothy Nikkel (:tnikkel) 2010-09-22 11:25:15 PDT
I think Felipe is looking into another bug where we freeze while resizing on Windows, maybe the same thing.
Comment 37 neil@parkwaycc.co.uk 2010-09-22 12:29:14 PDT
(In reply to comment #34)
> is it the case that Windows expects apps to respond to
> "messages" or "events" when their main window is being moved??
Normally window resizing is handled by the window's thread. In particular if the thread responds to the mouse click then the window border and title bar resizing is all done in-process, so you can't interact with the window if the thread stops responding during the drag. The thread also captures the pointer but as you noticed this only lasts as long as the window has focus.
Comment 38 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-09-23 12:50:50 PDT
This looks like a dupe of bug 575515 to me.

*** This bug has been marked as a duplicate of bug 575515 ***
Comment 39 Bas Schouten (:bas.schouten) 2010-10-12 12:44:25 PDT
*** Bug 603729 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.