Closed Bug 571507 Opened 14 years ago Closed 13 years ago

Crash [@ mozilla::layers::ContainerLayerD3D9::RenderLayer() ]

Categories

(Core :: Graphics, defect)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla10
Tracking Status
status2.0 --- ?

People

(Reporter: divjot94, Assigned: jgilbert)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file, 3 obsolete files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a6pre) Gecko/20100611 Firefox 3.6.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a6pre) Gecko/20100611 Firefox 3.6.3 more info @ http://crash-stats.mozilla.com/report/index/bp-54bcb8dd-db0b-4f1c-910b-053cd2100611 I really don't know what it is , but it crashed on me when i clicked the aero frame after viewing WebM video , first i thought it was WebM problem , but then seeing about:crashes i saw this D3D9 Layers thing. Sorry im not novice at all this , but there is really no related bug , so filing this Reproducible: Always Steps to Reproduce: Clicking aero frame with maybe Direct2D enabled Actual Results: Crash (Not always) Expected Results: No crashes
So does this mean its fixed?
Severity: major → critical
Component: Shell Integration → General
Keywords: crash
QA Contact: shell.integration → general
Summary: Crash on 3.7a5pre (20100610) due to ContainerLayerD3D9 RenderLayer() problem → Crash on 3.7a5pre (20100610) due to ContainerLayerD3D9 RenderLayer() problem [@ mozilla::layers::ContainerLayerD3D9::RenderLayer() ]
Version: unspecified → Trunk
This crash signature is back since b6pre/20100906 build.The crash daily rate is about 1-7 crashes/day.It happens with every kind of graphic cards.For me, clicking on aero frames does not crash FF.Signature mozilla::layers::ContainerLayerD3D9::RenderLayer()UUID 62c52c3e-7116-4ba1-aad2-7b6c12100920Time 2010-09-20 00:12:39.91841Uptime 533Last Crash 239062 seconds (2.8 days) before submissionInstall Age 533 seconds (8.9 minutes) since version was first installed.Product FirefoxVersion 4.0b7preBuild ID 20100919042023Branch 2.0OS Windows NTOS Version 6.1.7600CPU x86CPU Info GenuineIntel family 6 model 15 stepping 6Crash Reason EXCEPTION_ACCESS_VIOLATION_READCrash Address 0x0User Comments App Notes AdapterVendorID: 8086, AdapterDeviceID: 29a2Crashing ThreadFrame Module Signature [Expand] Source0 xul.dll mozilla::layers::ContainerLayerD3D9::RenderLayer gfx/layers/d3d9/ContainerLayerD3D9.cpp:1591 xul.dll mozilla::layers::ContainerLayerD3D9::RenderLayer gfx/layers/d3d9/ContainerLayerD3D9.cpp:2212 xul.dll mozilla::layers::ContainerLayerD3D9::RenderLayer gfx/layers/d3d9/ContainerLayerD3D9.cpp:2213 xul.dll mozilla::layers::LayerManagerD3D9::Render gfx/layers/d3d9/LayerManagerD3D9.cpp:2914 xul.dll mozilla::layers::LayerManagerD3D9::EndTransaction gfx/layers/d3d9/LayerManagerD3D9.cpp:1595 xul.dll nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:4526 xul.dll nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:14297 xul.dll PresShell::Paint layout/base/nsPresShell.cpp:60898 xul.dll nsViewManager::RenderViews view/src/nsViewManager.cpp:4479 xul.dll nsViewManager::Refresh view/src/nsViewManager.cpp:41310 xul.dll nsViewManager::DispatchEvent view/src/nsViewManager.cpp:91311 xul.dll AttachedHandleEvent view/src/nsView.cpp:19312 xul.dll nsWindow::DispatchEvent widget/src/windows/nsWindow.cpp:355613 xul.dll nsWindow::DispatchWindowEvent widget/src/windows/nsWindow.cpp:358714 @0x4330e3f
Status: UNCONFIRMED → NEW
status2.0: --- → ?
Component: General → Graphics
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → thebes
Summary: Crash on 3.7a5pre (20100610) due to ContainerLayerD3D9 RenderLayer() problem [@ mozilla::layers::ContainerLayerD3D9::RenderLayer() ] → Crash [@ mozilla::layers::ContainerLayerD3D9::RenderLayer() ]
Sorry for comment 3 formatting, but Bugzilla removes end of line of the current comment when product and component are also changed. This crash signature is back since b6pre/20100906 build. The crash daily rate is about 1-7 crashes/day. It happens with every kind of graphic cards. For me, clicking on aero frames does not crash FF. Signature mozilla::layers::ContainerLayerD3D9::RenderLayer() UUID 62c52c3e-7116-4ba1-aad2-7b6c12100920 Time 2010-09-20 00:12:39.91841 Uptime 533 Last Crash 239062 seconds (2.8 days) before submission Install Age 533 seconds (8.9 minutes) since version was first installed. Product Firefox Version 4.0b7pre Build ID 20100919042023 Branch 2.0 OS Windows NT OS Version 6.1.7600 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 6 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x0 AdapterVendorID: 8086, AdapterDeviceID: 29a2 Crashing Thread Frame Module Signature [Expand] Source 0 xul.dll mozilla::layers::ContainerLayerD3D9::RenderLayer gfx/layers/d3d9/ContainerLayerD3D9.cpp:159 1 xul.dll mozilla::layers::ContainerLayerD3D9::RenderLayer gfx/layers/d3d9/ContainerLayerD3D9.cpp:221 2 xul.dll mozilla::layers::ContainerLayerD3D9::RenderLayer gfx/layers/d3d9/ContainerLayerD3D9.cpp:221 3 xul.dll mozilla::layers::LayerManagerD3D9::Render gfx/layers/d3d9/LayerManagerD3D9.cpp:291 4 xul.dll mozilla::layers::LayerManagerD3D9::EndTransaction gfx/layers/d3d9/LayerManagerD3D9.cpp:159 5 xul.dll nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:452 6 xul.dll nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1429 7 xul.dll PresShell::Paint layout/base/nsPresShell.cpp:6089 8 xul.dll nsViewManager::RenderViews view/src/nsViewManager.cpp:447 9 xul.dll nsViewManager::Refresh view/src/nsViewManager.cpp:413 10 xul.dll nsViewManager::DispatchEvent view/src/nsViewManager.cpp:913 11 xul.dll AttachedHandleEvent view/src/nsView.cpp:193 12 xul.dll nsWindow::DispatchEvent widget/src/windows/nsWindow.cpp:3556 13 xul.dll nsWindow::DispatchWindowEvent widget/src/windows/nsWindow.cpp:3587 14 @0x4330e3f
Crash Signature: [@ mozilla::layers::ContainerLayerD3D9::RenderLayer() ]
Current location on MXR of "renderTexture->GetSurfaceLevel(0, getter_AddRefs(renderSurface));" is http://mxr.mozilla.org/mozilla-central/source/gfx/layers/d3d9/ContainerLayerD3D9.cpp#188 I don't know much about d3d, but could it be an instance where the texture fails to be created properly, then has GetSurfaceLevel called on it?
Assignee: nobody → jgilbert
Status: NEW → ASSIGNED
Messed up an indent.
Attachment #565694 - Attachment is obsolete: true
Attachment #565695 - Flags: review?(bas.schouten)
Attachment #565694 - Flags: review?(bas.schouten)
Jeff / Bas: Do you think we also need a check for failures here? http://mxr.mozilla.org/mozilla-central/source/gfx/layers/d3d10/LayerManagerD3D10.cpp#599 579 void 580 LayerManagerD3D10::UpdateRenderTarget() 581 { 582 if (mRTView) { 583 return; 584 } 585 586 HRESULT hr; 587 588 nsRefPtr<ID3D10Texture2D> backBuf; 589 590 if (mSwapChain) { 591 hr = mSwapChain->GetBuffer(0, __uuidof(ID3D10Texture2D), (void**)backBuf.StartAssignment()); 592 if (FAILED(hr)) { 593 return; 594 } 595 } else { 596 backBuf = mBackBuffer; 597 } 598 599 mDevice->CreateRenderTargetView(backBuf, NULL, getter_AddRefs(mRTView)); 600 } http://mxr.mozilla.org/mozilla-central/source/gfx/layers/d3d10/ImageLayerD3D10.cpp#490 490 mDevice->CreateTexture2D(&texDesc, NULL, getter_AddRefs(surfTexture)); Thanks, -Seth
Comment on attachment 565695 [details] [diff] [review] Adds checks for failure after CreateTexture(2D) in D3D9/10 layers code Review of attachment 565695 [details] [diff] [review]: ----------------------------------------------------------------- You're using nsDependentCString in D3D10, and NS_LITERAL_STRING in D3D9, any particular reason? I never quite understand our string logic but I think the latter is more appropriate. ::: gfx/layers/d3d10/ContainerLayerD3D10.cpp @@ +212,5 @@ > + if (FAILED(hr)) { > + LayerManagerD3D10::ReportFailure(nsDependentCString("Failed to create render target view for immediate ContainerLayerD3D10::RenderLayer"), > + hr); > + return; > + } I don't think we need to check the result of CreateRenderTarget view. If the texture is valid this will succeed. ::: gfx/layers/d3d9/ImageLayerD3D9.cpp @@ +459,5 @@ > + getter_AddRefs(tmpCbTexture), NULL); > + if (!FAILED(hr)) > + hr = aDevice->CreateTexture(mData.mCbCrSize.width, mData.mCbCrSize.height, > + 1, 0, D3DFMT_L8, D3DPOOL_SYSTEMMEM, > + getter_AddRefs(tmpCrTexture), NULL); nit: I know it's ugly here, but { } should still apply :) Especially in this multi-line case.
Attachment #565695 - Flags: review?(bas.schouten) → review+
(In reply to Bas Schouten (:bas) from comment #9) > Comment on attachment 565695 [details] [diff] [review] [diff] [details] [review] > Adds checks for failure after CreateTexture(2D) in D3D9/10 layers code > > Review of attachment 565695 [details] [diff] [review] [diff] [details] [review]: > ----------------------------------------------------------------- > > You're using nsDependentCString in D3D10, and NS_LITERAL_STRING in D3D9, any > particular reason? I never quite understand our string logic but I think the > latter is more appropriate. I don't have a good grip on it either, unfortunately. I think I did it because nearby code was written as such, but looking at it again, I'm not really seeing that. I'll upload one with just NS_LITERAL_STRINGs. > > ::: gfx/layers/d3d10/ContainerLayerD3D10.cpp > @@ +212,5 @@ > > + if (FAILED(hr)) { > > + LayerManagerD3D10::ReportFailure(nsDependentCString("Failed to create render target view for immediate ContainerLayerD3D10::RenderLayer"), > > + hr); > > + return; > > + } > > I don't think we need to check the result of CreateRenderTarget view. If the > texture is valid this will succeed. Ok, will remove. > ::: gfx/layers/d3d9/ImageLayerD3D9.cpp > @@ +459,5 @@ > > + getter_AddRefs(tmpCbTexture), NULL); > > + if (!FAILED(hr)) > > + hr = aDevice->CreateTexture(mData.mCbCrSize.width, mData.mCbCrSize.height, > > + 1, 0, D3DFMT_L8, D3DPOOL_SYSTEMMEM, > > + getter_AddRefs(tmpCrTexture), NULL); > > nit: I know it's ugly here, but { } should still apply :) Especially in this > multi-line case. True, will fix.
Update reflecting review comments, and fixed a bug with a cluster of missing HRESULT assignments, and added a check as per Seth's comment above.
Attachment #565695 - Attachment is obsolete: true
Attachment #570909 - Flags: review?(bas.schouten)
Comment on attachment 570909 [details] [diff] [review] Adds checks for failure after CreateTexture(2D) in D3D9/10 layers code Review of attachment 570909 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. ::: gfx/layers/d3d10/ImageLayerD3D10.cpp @@ +409,5 @@ > dataCr.pSysMem = mData.mCrChannel; > dataCr.SysMemPitch = mData.mCbCrStride; > > + HRESULT hr = mDevice->CreateTexture2D(&descY, &dataY, getter_AddRefs(mYTexture)); > + if (!FAILED(hr)) hr = mDevice->CreateTexture2D(&descCbCr, &dataCb, getter_AddRefs(mCbTexture)); I really prefer { }, but if noone else objects feel free to leave this :)
Attachment #570909 - Flags: review?(bas.schouten) → review+
Added brackets as per most recent review, and fixed where I accidentally a return value.
Attachment #570909 - Attachment is obsolete: true
Attachment #571573 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
(In reply to Bas Schouten (:bas) from comment #12) > > + HRESULT hr = mDevice->CreateTexture2D(&descY, &dataY, getter_AddRefs(mYTexture)); > > + if (!FAILED(hr)) hr = mDevice->CreateTexture2D(&descCbCr, &dataCb, getter_AddRefs(mCbTexture)); > > I really prefer { }, but if noone else objects feel free to leave this :) Body of the if on the same line as the if itself is always wrong and bad! (You can't set a breakpoint inside the if!)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: