609049 - Silverlight GPU accelerated app crashes when "Use HW Acceleration when available" is set [@ gfxContext::Translate]

Status: RESOLVED DUPLICATE of bug 620799

(Core Graveyard :: Plug-ins, defect)

Description

[Sunil]

Attachment: Files to repro the issue

With 64 bit FF Beta 8 (aka Minefield), HW Rendering crashes with a EXC_BREAKPOINT when the "Use HW Acceleration when available option" is selected.  Unselecting this option (Prefences, Advanced), allows SL to use the HW rendering path without crashing.  I verfied that HW rednering path was still being used with the option unselected.

Note: This bug requires a pre-release version of Silverlight that has Cocoa event model enabled for FF4. 

Repro steps -
1. Unzip the attached files.
2. Open FullScreenTestPage.html. 
3. Press the button to go into fullscreen.  

Result - nothing is rendered and an exception is logged in the console.

Comment 1

[aravindm]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b8pre) Gecko/20101111 Firefox/4.0b8pre

Able to reproduce. Nothing is rendered, when entering full screen mode. Just a blank screen. 

Error console : 
Error: Unhandled Error in Silverlight Application 
Code: 1001    
Category: RuntimeError       
Message: 1001 An error has occurred.     
MethodName:      
Source File: file:///Users/brundakumar/Desktop/FF4Fullscreen/FullscreenTestPage.html
Line: 54

Comment 2

[Sunil]

If you're running on OSX 10.5 with FF 4.0b8, are you running in 64 bit mode or 32 bit mode?

Comment 3

[aravindm]

(In reply to comment #2)
> If you're running on OSX 10.5 with FF 4.0b8, are you running in 64 bit mode or
> 32 bit mode?

I am running on MAC OSX 10.5 32-bit mode.

Comment 4

[juan becerra [:juanb]]

Josh, should this block beta or final?

Comment 5

[Josh Aas]

From what has been posted so far I doubt this is a Mozilla bug. Has someone at Microsoft looked into this?

Comment 6

[Sunil]

Josh, Chris has looked at it. The reason we think it's on Mozilla's side of things is because if we turn off browser H/W acceleration, everything works fine.

Comment 7

[Josh Aas]

Ah, I thought the reporter was talking about a Silverlight hardware acceleration option. Thanks.

Comment 8

[Josh Aas]

I can't reproduce this. The test case given here requires the debug version of the plugin (otherwise it'll fail looking for the debug config app) but with the debug version of the plugin things render just fine.

Comment 9

[Andy Rivas]

The bug should have been very easy to reproduce no matter what version you have installed.  I've just tried with the latest nightly and our latest build, which you should have, and was not able to repro either.  I'm getting verification from our test who filed the issue in our bug database.

Comment 10

[Josh Aas]

I can reproduce this now by running the currently stable (not pre-release) Silverlight plugin in Minefield on Mac OS X 10.6.5 in 32-bit mode.

Comment 11

[Josh Aas]

Crash report:

http://crash-stats.mozilla.com/report/index/31c31cb1-4468-4359-ac78-ef1b22101221

Comment 12

[timeless]

Signature	gfxContext::Translate
UUID	31c31cb1-4468-4359-ac78-ef1b22101221
Time	2010-12-21 06:57:09.193948
Uptime	86
Install Age	73679 seconds (20.5 hours) since version was first installed.
Product	Firefox
Version	4.0b9pre
Build ID	20101220030345
Branch	2.0
OS	Mac OS X
OS Version	10.6.5 10H574
CPU	x86
CPU Info	 family 6 model 44 stepping 2
Crash Reason	EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE
Crash Address	0x4
User Comments	
App Notes	Renderers: 0x21b00,0x20400
Processor Notes	
EMCheckCompatibility	False
Crashing Thread

Frame	Module	Signature [Expand]	Source
0	XUL	gfxContext::Translate	gfx/thebes/gfxContext.cpp:278
1	XUL	mozilla::layers::BasicBufferOGL::BeginPaint	gfx/layers/opengl/ThebesLayerOGL.cpp:463
2	XUL	mozilla::layers::ThebesLayerOGL::RenderLayer	gfx/layers/opengl/ThebesLayerOGL.cpp:546
3	XUL	mozilla::layers::ContainerLayerOGL::RenderLayer	gfx/layers/opengl/ContainerLayerOGL.cpp:236
4	XUL	mozilla::layers::ContainerLayerOGL::RenderLayer	gfx/layers/opengl/ContainerLayerOGL.cpp:236
5	XUL	mozilla::layers::LayerManagerOGL::Render	gfx/layers/opengl/LayerManagerOGL.cpp:600
6	XUL	mozilla::layers::LayerManagerOGL::EndTransaction	gfx/layers/opengl/LayerManagerOGL.cpp:418
7	XUL	nsDisplayList::PaintForFrame	layout/base/nsDisplayList.cpp:477
8	XUL	nsDisplayList::PaintRoot	layout/base/nsDisplayList.cpp:384
9	XUL	nsLayoutUtils::PaintFrame	layout/base/nsLayoutUtils.cpp:1433
10	XUL	PresShell::Paint	layout/base/nsPresShell.cpp:6095
11	XUL	nsViewManager::RenderViews	view/src/nsViewManager.cpp:447
12	XUL	nsViewManager::Refresh	view/src/nsViewManager.cpp:413
13	XUL	nsViewManager::DispatchEvent	view/src/nsViewManager.cpp:912
14	XUL	HandleEvent	view/src/nsView.cpp:161
15	XUL	nsChildView::DispatchEvent	widget/src/cocoa/nsChildView.mm:1786
16	XUL	nsChildView::DispatchWindowEvent	widget/src/cocoa/nsChildView.mm:1796
17	XUL	-[ChildView drawRect:inContext:]	widget/src/cocoa/nsChildView.mm:2728
18	XUL	-[ChildView drawRect:]	widget/src/cocoa/nsChildView.mm:2632
19	AppKit	-[NSView _drawRect:clip:]	
20	AppKit	-[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:]	
21	AppKit	-[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:]	
22	AppKit	-[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:]	
23	AppKit	-[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]	
24	AppKit	-[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]	
25	AppKit	-[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]	
26	AppKit	-[NSView displayIfNeeded]	
27	AppKit	-[NSWindow displayIfNeeded]	
28	AppKit	_handleWindowNeedsDisplay	
29	CoreFoundation	__CFRunLoopDoObservers	
30	CoreFoundation	__CFRunLoopRun

Comment 14

[timeless]

yes, this is a dupe maze, sorry.