Closed
Bug 593779
Opened 14 years ago
Closed 14 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)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: scoobidiver, Assigned: bas.schouten)
References
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
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 1•14 years ago
|
||
Any steps to reproduce? I can try catching this with a stack in a debugger if so.
Comment 2•14 years ago
|
||
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.
Reporter | ||
Comment 3•14 years ago
|
||
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 ....
Reporter | ||
Comment 4•14 years ago
|
||
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
Assignee | ||
Comment 5•14 years ago
|
||
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.
Comment 6•14 years ago
|
||
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.
Comment 7•14 years ago
|
||
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()
Assignee | ||
Comment 8•14 years ago
|
||
We should find the error value that is returned by CreateTexture here.
Comment 9•14 years ago
|
||
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
Comment 10•14 years ago
|
||
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).
Comment 11•14 years ago
|
||
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.
Updated•14 years ago
|
Summary: [D3D9] crash [@ xul.dll@0x6a....] with ATI graphic card → [D3D9] crash [@ xul.dll@0x6a....] with ATI graphic card (maybe only with CrossFireX enabled)
Comment 12•14 years ago
|
||
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.
Reporter | ||
Comment 13•14 years ago
|
||
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
Comment 15•14 years ago
|
||
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
Reporter | ||
Comment 16•14 years ago
|
||
> 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.
Reporter | ||
Comment 17•14 years ago
|
||
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) ]
Comment 18•14 years ago
|
||
This will probably be fixed by the Direct3D 10 Layers backend.
blocking2.0: ? → betaN+
Reporter | ||
Comment 19•14 years ago
|
||
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.
Assignee | ||
Comment 20•14 years ago
|
||
(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!
Updated•14 years ago
|
Assignee: nobody → bas.schouten
Assignee | ||
Comment 21•14 years ago
|
||
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
Updated•14 years ago
|
blocking2.0: ? → -
Reporter | ||
Comment 22•14 years ago
|
||
I don't see this crash signature anymore. I close this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Updated•13 years ago
|
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.
Description
•