Closed Bug 593779 Opened 9 years ago Closed 9 years ago

[D3D9] crash with some NVIDIA and ATI graphic cards (may be only with CrossFireX enabled) [@ xul.dll@0x6.....] [@ cairo_d2d_surface_create_for_handle(_cairo_device * device, void * handle, _cairo_content content) ]

Categories

(Core :: Graphics, defect, critical)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
blocking2.0 --- -

People

(Reporter: scoobidiver, Assigned: bas.schouten)

References

(Blocks 2 open bugs)

Details

(Keywords: crash, regression)

Crash Data

Build : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100905 Firefox/4.0b6pre

This is a new crash signature which has been introduced by this build.
It is #2 top crasher for this build.
There is no symbol in the crash thread.

Signature	xul.dll@0x6acf44
UUID	3538eeec-22b6-401a-b6a0-d6b302100906
Time 	2010-09-06 02:45:46.159227
Uptime	1123
Last Crash	1129 seconds (18.8 minutes) before submission
Install Age	34297 seconds (9.5 hours) since version was first installed.
Product	Firefox
Version	4.0b6pre
Build ID	20100905041304
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 26 stepping 4
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x0
User Comments	
App Notes 	AdapterVendorID: 1002, AdapterDeviceID: 9441
Processor Notes 	
EMCheckCompatibility	False
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	xul.dll@0x6acf44 	
1 	xul.dll 	xul.dll@0x6ad3aa 	
2 	xul.dll 	xul.dll@0x5d90db 	
3 	xul.dll 	xul.dll@0x5d90db 	
4 	xul.dll 	xul.dll@0x6adb4d 	
5 	xul.dll 	xul.dll@0x6adbc4 	
6 	xul.dll 	xul.dll@0x1568c3 	
7 	xul.dll 	xul.dll@0x26193d 	
8 	xul.dll 	xul.dll@0x23c92a 	

The regression window is :
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bd474ff6f86c&tochange=fd13b6ce36bd
blocking2.0: --- → ?
Any steps to reproduce? I can try catching this with a stack in a debugger if so.
I'm seeing this on Win 7/x86_64 as well.  Video card is 2x ATI 4870 512MB in Crossfire with the latest Catalyst drivers (10.8)--I noticed that the reporter's adapter vendor ID is also ATI.

Very frequent crashes when scrolling, closing tabs, etc.  I reproduced the crash with the MSVC 2010 debugger attached and the crash passed right through to the crash reporter.  I suspect this is caused by bug 581212, but I haven't disabled layers.accelerate-all to confirm yet.
As the crash signature is a moving one (no symbol) :
* b6pre/20100904 build : xul.dll@0x6ace33
* b6pre/20100905 build : xul.dll@0x6acf44
* b6pre/20100906 build : xul.dll@0x6ac10a
* .....
the regression range in comment 0 is wrong. The right one is :
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4b879b793eb6&tochange=bd474ff6f86c
Summary: Crash [@ xul.dll@0x6acf44 ] → Crash [@ xul.dll@0x6a....] : [@ xul.dll@0x6ace33] or [@ xul.dll@0x6acf44 ] or [@ xul.dll@0x6ac10a ] or ....
After analyzing one day of crash with the today's crash signature xul.dll@0x6a9b75, only ATI cards are implied. The graphic driver version is recent in all the case : catalyst 10.7 or 10.8.
VendorId  DeviceId  atidxx32.dll  CardName
1002  689c  8.17.10.299  HD 5900 series
1002  9460  8.17.10.299  HD 4800 series
1002  9441  8.17.10.299  HD 4870 X2
1002  68b8  8.17.10.299  HD 5700 series
1002  6899  8.17.10.292  HD 5800 series
1002  950f  8.17.10.292  HD 3870 X2
1002  9443  8.17.10.299  unknown

As these crashes have happened since D3D9 was enabled by default, this is a D3D9 issue.
Blocks: d3d9-layers
Component: General → Graphics
QA Contact: general → thebes
Summary: Crash [@ xul.dll@0x6a....] : [@ xul.dll@0x6ace33] or [@ xul.dll@0x6acf44 ] or [@ xul.dll@0x6ac10a ] or .... → [D3D9] crash [@ xul.dll@0x6a....] with ATI graphic card
Kinetik: Can you break MSVC on handled exceptions so we can maybe get symbols on this? I can't seem to reproduce this on my 5800 series card.
I would, but the currently nightlies are stable for me.  I went back to the 20101005 nightlies and they didn't crash with the debugger attached during 3-4 hours of browsing.
It turns out I had disabled D2D to test if that resolved the crash, then completely forgot about disabling it.  Having reenabled it, the current nightly still crashes easily for me.  I caught a crash while scrolling in the debugger:



With thrown exceptions caught, an exception is thrown here:

KernelBase.dll!_RaiseException@16()  + 0x58 bytes	
msvcrt.dll!__CxxThrowException@8()  + 0x45 bytes	
d3d10_1core.dll!ThrowFailure()  + 0x2f bytes	
d3d10_1core.dll!CDevice::QueryAndOpenSharedResource()  + 0x5d bytes	
d3d10_1core.dll!CDevice::OpenSharedResourceInternal()  + 0x91 bytes	
d3d10_1core.dll!CDevice::ID3D10Device1_OpenSharedResource_()  + 0x1c bytes	
d3d10_1core.dll!NMultithread::CDevice::OpenSharedResource()  + 0x3c bytes	
xul.dll!cairo_d2d_surface_create_for_handle(_cairo_device * device, void * handle, _cairo_content content)  Line 3566	C++
xul.dll!gfxD2DSurface::gfxD2DSurface(void * handle, gfxASurface::gfxContentType aContent)  Line 54 + 0x1f bytes	C++
xul.dll!mozilla::layers::ThebesLayerD3D9::CreateNewTexture(const gfxIntSize & aSize)  Line 460 + 0x31 bytes	C++
xul.dll!mozilla::layers::ThebesLayerD3D9::SetVisibleRegion(const nsIntRegion & aRegion)  Line 112	C++
xul.dll!mozilla::`anonymous namespace'::ContainerState::PopThebesLayerData()  Line 822	C++
xul.dll!mozilla::`anonymous namespace'::ContainerState::Finish()  Line 1313 + 0xd bytes	C++
xul.dll!mozilla::FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder * aBuilder, mozilla::layers::LayerManager * aManager, nsIFrame * aContainerFrame, nsDisplayItem * aContainerItem, const nsDisplayList & aChildren)  Line 1403	C++
xul.dll!nsDisplayOwnLayer::BuildLayer(nsDisplayListBuilder * aBuilder, mozilla::layers::LayerManager * aManager)  Line 1286	C++
xul.dll!mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems(const nsDisplayList & aList, const mozilla::FrameLayerBuilder::Clip & aClip)  Line 1087 + 0x1c bytes	C++
xul.dll!mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems(const nsDisplayList & aList, const mozilla::FrameLayerBuilder::Clip & aClip)  Line 1059	C++
xul.dll!mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems(const nsDisplayList & aList, const mozilla::FrameLayerBuilder::Clip & aClip)  Line 1059	C++
xul.dll!mozilla::`anonymous namespace'::ContainerState::ProcessDisplayItems(const nsDisplayList & aList, const mozilla::FrameLayerBuilder::Clip & aClip)  Line 1059	C++
xul.dll!mozilla::FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder * aBuilder, mozilla::layers::LayerManager * aManager, nsIFrame * aContainerFrame, nsDisplayItem * aContainerItem, const nsDisplayList & aChildren)  Line 1401	C++
xul.dll!nsDisplayList::PaintForFrame(nsDisplayListBuilder * aBuilder, nsIRenderingContext * aCtx, nsIFrame * aForFrame, unsigned int aFlags)  Line 407 + 0x1c bytes	C++
xul.dll!nsLayoutUtils::PaintFrame(nsIRenderingContext * aRenderingContext, nsIFrame * aFrame, const nsRegion & aDirtyRegion, unsigned int aBackstop, unsigned int aFlags)  Line 1424	C++
xul.dll!PresShell::Paint(nsIView * aDisplayRoot, nsIView * aViewToPaint, nsIWidget * aWidgetToPaint, const nsRegion & aDirtyRegion, const nsIntRegion & aIntDirtyRegion, int aPaintDefaultBackground, int aWillSendDidPaint)  Line 5951	C++
xul.dll!nsViewManager::RenderViews(nsView * aView, nsIWidget * aWidget, const nsRegion & aRegion, const nsIntRegion & aIntRegion, int aPaintDefaultBackground, int aWillSendDidPaint)  Line 448	C++
xul.dll!nsViewManager::Refresh(nsView * aView, nsIWidget * aWidget, const nsIntRegion & aRegion, unsigned int aUpdateFlags)  Line 415	C++
xul.dll!nsViewManager::DispatchEvent(nsGUIEvent * aEvent, nsIView * aView, nsEventStatus * aStatus)  Line 931 + 0x12 bytes	C++
xul.dll!AttachedHandleEvent(nsGUIEvent * aEvent)  Line 194	C++
xul.dll!nsWindow::DispatchEvent(nsGUIEvent * event, nsEventStatus & aStatus)  Line 3548	C++
xul.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event, nsEventStatus & aStatus)  Line 3577	C++
xul.dll!__SEH_epilog4_GS()  + 0x12a845 bytes	C++
15e2e7e0()	



After allowing the debugger to pass the exception to the debuggee:

xul.dll!mozilla::layers::ThebesLayerD3D9::DrawRegion(const nsIntRegion & aRegion)  Line 362 + 0x3 bytes	C++
xul.dll!mozilla::layers::ThebesLayerD3D9::RenderLayer()  Line 219	C++
xul.dll!mozilla::layers::ContainerLayerD3D9::RenderLayer()  Line 221	C++
xul.dll!mozilla::layers::ContainerLayerD3D9::RenderLayer()  Line 221	C++
xul.dll!mozilla::layers::LayerManagerD3D9::Render()  Line 270	C++
xul.dll!mozilla::layers::LayerManagerD3D9::EndTransaction(void (mozilla::layers::ThebesLayer *, gfxContext *, const nsIntRegion &, const nsIntRegion &, void *)* aCallback, void * aCallbackData)  Line 137	C++
xul.dll!nsDisplayList::PaintForFrame(nsDisplayListBuilder * aBuilder, nsIRenderingContext * aCtx, nsIFrame * aForFrame, unsigned int aFlags)  Line 419	C++
xul.dll!nsLayoutUtils::PaintFrame(nsIRenderingContext * aRenderingContext, nsIFrame * aFrame, const nsRegion & aDirtyRegion, unsigned int aBackstop, unsigned int aFlags)  Line 1424	C++
xul.dll!PresShell::Paint(nsIView * aDisplayRoot, nsIView * aViewToPaint, nsIWidget * aWidgetToPaint, const nsRegion & aDirtyRegion, const nsIntRegion & aIntDirtyRegion, int aPaintDefaultBackground, int aWillSendDidPaint)  Line 5951	C++
xul.dll!nsViewManager::RenderViews(nsView * aView, nsIWidget * aWidget, const nsRegion & aRegion, const nsIntRegion & aIntRegion, int aPaintDefaultBackground, int aWillSendDidPaint)  Line 448	C++
xul.dll!nsViewManager::Refresh(nsView * aView, nsIWidget * aWidget, const nsIntRegion & aRegion, unsigned int aUpdateFlags)  Line 415	C++
xul.dll!nsViewManager::DispatchEvent(nsGUIEvent * aEvent, nsIView * aView, nsEventStatus * aStatus)  Line 931 + 0x12 bytes	C++
xul.dll!AttachedHandleEvent(nsGUIEvent * aEvent)  Line 194	C++
xul.dll!nsWindow::DispatchEvent(nsGUIEvent * event, nsEventStatus & aStatus)  Line 3548	C++
xul.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event, nsEventStatus & aStatus)  Line 3577	C++
xul.dll!__SEH_epilog4_GS()  + 0x12a845 bytes	C++
15e2e7e0()
We should find the error value that is returned by CreateTexture here.
It returns E_INVALIDARG after raising the exception (first stack).  With the D3D10 and D3D9 debugging stuff enabled, this is logged as the exception is thrown:

Direct3D9: (ERROR) :Error during initialization of texture. CreateTexture failed.
Direct3D9: (ERROR) :Failure trying to create a texture
D3D10: CORRUPTION: ID3D10Device::OpenSharedResource: First parameter corrupt or NULL. [ MISCELLANEOUS CORRUPTION #13: CORRUPTED_PARAMETER1 ]
First-chance exception at 0x7797b727 (KernelBase.dll) in firefox.exe: 0x0000087A: 0x87a.

handle is 0x0
&newSurf->surface.mPtr is 0x0
Additional info:

- Crash still occurs with latest Catalyst 10.9 drivers.

- Crash doesn't seem to happen when CrossfireX is disabled; no crash after browsing for ~30 mins with CrossfireX disabled--then two crashes within ~5 mins with CrossfireX re-enabled (browser restarted between changes).
HRESULT of failing CreateTexture call is 0x8876017c (D3DERR_OUTOFVIDEOMEMORY).  Once this fails, the process crashes due to an exception raised in the first stack pasted above--therefore the |new gfxD2DSurface| call in ThebesLayerD3D9::CreateNewTexture never returns.

If I change the code to avoid calling that if FAILED(hr) to allow the code to fall through to the second CreateTexture call (inside |if (!mTexture)|), the crash does not occur but I start seeing flashes of black covering the entire browser window which go away when opening new tabs or otherwise forcing a redraw.

Once the first CreateTexture call fails, the printf logging I added suggests that many (maybe all?) subsequent calls are also failing and we're hitting the fallback path.
Summary: [D3D9] crash [@ xul.dll@0x6a....] with ATI graphic card → [D3D9] crash [@ xul.dll@0x6a....] with ATI graphic card (maybe only with CrossFireX enabled)
Oh, forgot to add this: for anyone attempting to reproduce, I can hit this in under 60 seconds by opening http://m3forum.net/m3forum/forumdisplay.php?f=9, grabbing the scroll bar and scrolling up and down constantly (without releasing the left mouse button) until it crashes.  I doubt the site matters, that one just happens to be what I'm testing with.
Now in b7pre/20100919, FF crashes also with NVIDIA card :
Signature	xul.dll@0x6ea182
UUID	e0a7e9a5-0b60-46df-82a2-944f82100919
Summary: [D3D9] crash [@ xul.dll@0x6a....] with ATI graphic card (maybe only with CrossFireX enabled) → [D3D9] crash [@ xul.dll@0x6.....] with some ATI graphic cards (maybe only with CrossFireX enabled) and some NVIDIA graphic cards
It is now #1 top crasher for b7pre/20100923 build.
Not sure if it's related but I get lots of XUL.dll crashes with my (single) GTX480. The last 2 crashes were: xul.dll@0x26be04  and xul.dll@0x1c820d

Adapter Description NVIDIA GeForce GTX 480
Vendor ID10de
Device ID06c0
Adapter RAM1536
Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Driver Version 8.17.12.5896
Driver Date7-9-2010
Direct2D Enabled true 
DirectWrite Enabled true
GPU Accelerated Windows 1/1 Direct3D 9
> Not sure if it's related but I get lots of XUL.dll crashes with my (single)
> GTX480. The last 2 crashes were: xul.dll@0x26be04  and xul.dll@0x1c820d
No it is not related, the crash signature must look like xul.dll@0x6..... with "....." changing with each build and the number of frames must be 9.
If you can reproduce your crashes, please file a new bug for each different crash signature.
In the crash stats, I includes several crash signatures in the same build that look like xul.dll@0x6e or xul.dll@0x6f :
20100918 : 41
20100919 : 28
20100920 : 38
20100921 : 61
20100922 : 39
20100923 : 36
20100924 : 16
Summary: [D3D9] crash [@ xul.dll@0x6.....] with some ATI graphic cards (maybe only with CrossFireX enabled) and some NVIDIA graphic cards → [D3D9] crash with some NVIDIA and ATI graphic cards (may be only with CrossFireX enabled) [@ xul.dll@0x6.....] [@ cairo_d2d_surface_create_for_handle(_cairo_device * device, void * handle, _cairo_content content) ]
This will probably be fixed by the Direct3D 10 Layers backend.
blocking2.0: ? → betaN+
As there is no aggregate results for this moving signature, I think a list by top crasher number is more explicit:
b7pre/20100928 : #16
b7pre/20100929 : #9
b7pre/20100930 : #19
b7pre/20101002 : #14
b7pre/20101003 : #12 
b7pre/20101004 : #8

> This will probably be fixed by the Direct3D 10 Layers backend.
I hope Direct3D 10 will be enabled by default for beta 7.
(In reply to comment #19)
> As there is no aggregate results for this moving signature, I think a list by
> top crasher number is more explicit:
> b7pre/20100928 : #16
> b7pre/20100929 : #9
> b7pre/20100930 : #19
> b7pre/20101002 : #14
> b7pre/20101003 : #12 
> b7pre/20101004 : #8
> 
> > This will probably be fixed by the Direct3D 10 Layers backend.
> I hope Direct3D 10 will be enabled by default for beta 7.

It will not be, it will be enabled for Beta 8. That's mainly a planning thing though!
Assignee: nobody → bas.schouten
Blocks: 571756
No longer blocks: 571756
Blocks: 605749
Blocks: 605780
D3D10 is used by default now. Leaving it open because we haven't removed the D3D9/D2D code yet. But this should no longer block I believe.
Status: NEW → UNCONFIRMED
blocking2.0: betaN+ → ?
Ever confirmed: false
blocking2.0: ? → -
I don't see this crash signature anymore.
I close this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ xul.dll@0x6.....] [@ cairo_d2d_surface_create_for_handle(_cairo_device * device, void * handle, _cairo_content content) ]
You need to log in before you can comment on or make changes to this bug.