Closed Bug 595375 Opened 15 years ago Closed 13 years ago

Crash @ _d2d_compute_bitmap_mem_size

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla15
Tracking Flags:
Tracking Status
firefox13 --- fixed
firefox14 + fixed

People

(Reporter: marcia, Assigned: bas.schouten)

References

Details

(Keywords: crash, topcrash, Whiteboard: [newb5])

Crash Data

Attachments

(1 file)

Fail brush creation when bitmap creation fails
3.23 KB, patch
jrmuizel
: review+
akeybl
: approval-mozilla-aurora+
akeybl
: approval-mozilla-beta+
Details | Diff | Splinter Review
Harvested from chofmann's report, and new to B5. http://tinyurl.com/2fqstwa links to the reports, which are all Windows 7. Currently the #46 top crash in Beta 5. Frame Module Signature [Expand] Source 0 xul.dll _d2d_compute_bitmap_mem_size gfx/cairo/cairo/src/cairo-d2d-surface.cpp:1122 1 xul.dll _cairo_d2d_create_brush_for_pattern gfx/cairo/cairo/src/cairo-d2d-surface.cpp:1937 2 xul.dll _cairo_d2d_fill gfx/cairo/cairo/src/cairo-d2d-surface.cpp:3226 3 xul.dll _cairo_surface_fill gfx/cairo/cairo/src/cairo-surface.c:2216 4 xul.dll _cairo_gstate_fill gfx/cairo/cairo/src/cairo-gstate.c:1184 5 xul.dll _moz_cairo_fill_preserve gfx/cairo/cairo/src/cairo.c:2338 6 xul.dll gfxSurfaceDrawable::Draw gfx/thebes/gfxDrawable.cpp:139 7 xul.dll gfxUtils::DrawPixelSnapped gfx/thebes/gfxUtils.cpp:416 8 xul.dll imgFrame::Draw modules/libpr0n/src/imgFrame.cpp:499 9 xul.dll mozilla::imagelib::RasterImage::Draw modules/libpr0n/src/RasterImage.cpp:2453 10 xul.dll DrawImageInternal layout/base/nsLayoutUtils.cpp:3042 11 xul.dll ImageRenderer::Draw layout/base/nsCSSRendering.cpp:3867 12 xul.dll PaintBackgroundLayer layout/base/nsCSSRendering.cpp:2650 13 xul.dll nsCSSRendering::PaintBackgroundWithSC layout/base/nsCSSRendering.cpp:2373 14 xul.dll nsBCTableCellFrame::PaintBackground layout/tables/nsTableCellFrame.cpp:1194 15 xul.dll nsTableCellFrame::PaintCellBackground layout/tables/nsTableCellFrame.cpp:383 16 xul.dll TableBackgroundPainter::PaintCell layout/tables/nsTablePainter.cpp:675 17 xul.dll TableBackgroundPainter::PaintRow layout/tables/nsTablePainter.cpp:602 18 xul.dll TableBackgroundPainter::PaintRowGroup layout/tables/nsTablePainter.cpp:542 19 xul.dll TableBackgroundPainter::PaintTable layout/tables/nsTablePainter.cpp:458 20 xul.dll nsTableFrame::PaintTableBorderBackground layout/tables/nsTableFrame.cpp:1363 21 xul.dll nsDisplayTableBorderBackground::Paint layout/tables/nsTableFrame.cpp:1147 22 xul.dll mozilla::FrameLayerBuilder::DrawThebesLayer layout/base/FrameLayerBuilder.cpp:1507 23 xul.dll mozilla::layers::BasicThebesLayer::PaintBuffer gfx/layers/basic/BasicLayers.cpp:338 24 xul.dll mozilla::layers::BasicThebesLayer::Paint gfx/layers/basic/BasicLayers.cpp:419 25 xul.dll mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:1069 26 xul.dll mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:1077 27 xul.dll mozilla::layers::BasicLayerManager::PaintLayer gfx/layers/basic/BasicLayers.cpp:1077 28 xul.dll mozilla::layers::BasicLayerManager::EndTransaction gfx/layers/basic/BasicLayers.cpp:977 29 xul.dll nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:410 30 xul.dll nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1409 31 xul.dll PresShell::Paint layout/base/nsPresShell.cpp:5934 32 xul.dll nsViewManager::RenderViews view/src/nsViewManager.cpp:459 33 xul.dll nsViewManager::Refresh view/src/nsViewManager.cpp:425 34 xul.dll nsViewManager::DispatchEvent view/src/nsViewManager.cpp:940 35 xul.dll AttachedHandleEvent view/src/nsView.cpp:193 36 xul.dll nsWindow::DispatchEvent widget/src/windows/nsWindow.cpp:3524 37 xul.dll nsWindow::DispatchWindowEvent widget/src/windows/nsWindow.cpp:3555 38 xul.dll nsWindow::OnPaint widget/src/windows/nsWindowGfx.cpp:603 39 xul.dll nsWindow::ProcessMessage widget/src/windows/nsWindow.cpp:4734 40 xul.dll nsWindow::WindowProcInternal widget/src/windows/nsWindow.cpp:4326 41 xul.dll nsWindow::WindowProc widget/src/windows/nsWindow.cpp:4278 42 user32.dll InternalCallWinProc 43 user32.dll NtUserGetDC 44 user32.dll DispatchClientMessage 45 user32.dll __fnDWORD 46 ntdll.dll ntdll.dll@0x100e5 47 xul.dll nsWindow::Invalidate 48 xul.dll nsRunnableMethodImpl<void obj-firefox/dist/include/nsThreadUtils.h:347 49 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:110 50 xul.dll MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:219 51 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:202 52 xul.dll _SEH_epilog4 53 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:176 54 xul.dll nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:175 55 xul.dll nsAppShell::Run widget/src/windows/nsAppShell.cpp:243 56 xul.dll nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:191 57 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:3662 58 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:120 59 firefox.exe __tmainCRTStartup obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591 60 kernel32.dll kernel32.dll@0x13676 61 ntdll.dll ntdll.dll@0x39d41 62 ntdll.dll ntdll.dll@0x39d14
moving up to #31 on b5 yesterday with 42 crashes as the beta population grows 20100906 8 ,7 4.0b4,1 4.0b5, 20100907 9 ,4 4.0b5,4 4.0b4,1 4.0b6pre, 20100908 29 ,26 4.0b5,3 4.0b4, 20100909 42 4.0b5,42 , changes near the top of the stack might point to 2010-06-30 15:52 +0200 Bas Schouten - Bug 558467: Expose the image surface cache memory usage for Direct2D. r=jrmuizel Olli Pettay - Bug 518122, improve textarea.value+= performance, r=bz
> all the crash a ddresses appear to be 0x0 indeed. And for firefox 4.0b8 it is ~#160 crash thunderbird 3.3a crash bp-13388cae-aa49-41dc-a8a6-6298d2101220 (ubel) when viewing an email with a large picture attachment ~7.5mb (twice now) EXCEPTION_ACCESS_VIOLATION_READ 0x0 0 xul.dll _d2d_compute_bitmap_mem_size gfx/cairo/cairo/src/cairo-d2d-surface.cpp:1132 1 d3d10.dll d3d10.dll@0xe0493 2 xul.dll _cairo_d2d_fill gfx/cairo/cairo/src/cairo-d2d-surface.cpp:3391 3 xul.dll _cairo_surface_fill gfx/cairo/cairo/src/cairo-surface.c:2216 4 xul.dll _cairo_gstate_fill gfx/cairo/cairo/src/cairo-gstate.c:1184 5 xul.dll _moz_cairo_fill_preserve gfx/cairo/cairo/src/cairo.c:2338 6 xul.dll gfxContext::Fill gfx/thebes/gfxContext.cpp:151 7 xul.dll gfxSurfaceDrawable::Draw gfx/thebes/gfxDrawable.cpp:173 8 xul.dll CreateSamplingRestrictedDrawable gfx/thebes/gfxUtils.cpp:276 9 xul.dll gfxUtils::DrawPixelSnapped gfx/thebes/gfxUtils.cpp:400 10 xul.dll imgFrame::Draw modules/libpr0n/src/imgFrame.cpp:488 11 xul.dll mozilla::imagelib::RasterImage::Draw modules/libpr0n/src/RasterImage.cpp:2432 12 xul.dll DrawImageInternal layout/base/nsLayoutUtils.cpp:3081 13 xul.dll nsLayoutUtils::DrawSingleImage layout/base/nsLayoutUtils.cpp:3200 14 xul.dll nsImageFrame::PaintImage layout/generic/nsImageFrame.cpp:1221 15 xul.dll nsDisplayImage::Paint layout/generic/nsImageFrame.cpp:1204
Keywords: topcrash
Assignee: nobody → bas.schouten
Keywords: topcrash
Crash Signature: [@ _d2d_compute_bitmap_mem_size ]
#22 crash for Tbird v6. Estimate 80 reporters for 4 weeks.
Whiteboard: [newb5] → [newb5][tbird topcrash]
timeless, any thoughts on this? Bas, sorry, still no testcases from Thunderbird crash reporters. (Bas PM: "The only reason I could see this happening in the current tree is in an OOM situation. If we have any way to reproduce it I could try and diagnose it but right now I have no idea.") Brief profile of crash-stats ... Thunderbird crashes ... - approx 1/3 have dxgi.dll on stack like bp-b635fd-8cc0-4761-9b4a-eff6d2110913 - a small percentage have d3d10.dll, like bp-876ac302-892c-4efa-b04e-40c152110911 - some have igd10umd32 like bp-eea1e452-a1ac-41a0-9fc6-293d92110913 - some have d2d1.dll like bp-3df23340-952e-4881-8ec3-f09b12110913 and bp-5909ecfb-26b7-4ad3-883a-0e1ec2110911 - some unknown quantity have nothing other than mozilla, like bp-c3995728-7c3f-4c53-99ed-83c4b2110913 EXCEPTION_ACCESS_VIOLATION_READ 0x0 0 xul.dll _d2d_compute_bitmap_mem_size gfx/cairo/cairo/src/cairo-d2d-surface.cpp:1190 1 xul.dll gfxContext::Fill gfx/thebes/gfxContext.cpp:151 2 xul.dll nsCSSBorderRenderer::DrawNoCompositeColorSolidBorder layout/base/nsCSSRenderingBorders.cpp:1284 3 xul.dll gfxContext::Rectangle gfx/thebes/gfxContext.cpp:250 4 xul.dll gfxUtils::DrawPixelSnapped gfx/thebes/gfxUtils.cpp:417 5 xul.dll imgFrame::Draw modules/libpr0n/src/imgFrame.cpp:474 6 xul.dll mozilla::imagelib::RasterImage::Draw modules/libpr0n/src/RasterImage.cpp:2508 7 xul.dll DrawImageInternal layout/base/nsLayoutUtils.cpp:3293 8 xul.dll nsLayoutUtils::DrawSingleImage layout/base/nsLayoutUtils.cpp:3410 9 xul.dll nsImageFrame::PaintImage layout/generic/nsImageFrame.cpp:1285 10 xul.dll nsDisplayImage::Paint layout/generic/nsImageFrame.cpp:1195 11 xul.dll mozilla::FrameLayerBuilder::DrawThebesLayer layout/base/FrameLayerBuilder.cpp:1957 Firefox crashes... most mention nvidia drivers. Of crashes in the past week - four comments specifically mention nvidia gtx 460, eg bp-5fea9a21-1cd0-47fd-b766-d56f92110912 - two generically mention nvidia, like "crash after\with new last nVidia GeForce display driver. Win7 64" PMed these folks to get details about the video + crash bp-685df3e3-fd49-445d-98e1-4d3742110913 (Matt) bp-accdaac8-198f-4be2-95c0-c938f2110912 (alexander) bp-9d325e68-359a-4842-bae5-cd7792110912 (vltky) bp-282f2586-02a7-4265-ba36-e4df82110912 (steen)
Hi, was asked to provide some details. Nvidia GeForce GTX 560 TI Driver Version 280.26 After disabling 'hardware acceleration' in Firefox no more crashes from graphics driver and Firefox.
VT from bp-9d325e68-359a-4842-bae5-cd7792110912 writes: "nVidia GeForce GTX 560 Ti. Don’t think that Mozilla crashes video cards type hardware dependable. It’s come from 8.17.12.8026 nVidia video driver. My brother had the same problem. But with other - 430 card. He *uninstall latest driver and install previous. And no more crashes.* So you can check difference between two drivers version. Look/ask what they added and may be ask for nvidia’s help. " (so it crashes with *newer* driver!)
Note that right now, 280.26 WHQL is the latest official driver, so blacklisting it would probably affect a lot of users. Version 285.27 was just released in beta though.
Recently got same crash with FF10 Nightly: https://crash-stats.mozilla.com/report/index/bp-d7ead5a7-d93e-4049-8c16-3df6a2110917 I am using nvidia GTX 460. I noticed it start happening after nvidia forceware 280 series drivers and 280.26 is most crasher (at least for me), while 285 series beta driver crashes less than 280 series.
Want to add a info, maybe worthwhile for you, today I again once got nvidia driver crash, firefox was in minimize state with two tabs (one as app tab while other generally)(more specific one was rapidshare, while ld.rtify.com as pin tab), after monitor turned again, both tab showed black blank screen in aero peek window.
Bas, does the above information help you in any way?
Nothing obvious, but I'll look some more.
I manage to reduce this crash happening significantly while using simple registry trick in Windows by increasing TDR time. Should I share it here so people facing crashes may reduce it? In Actual, its an issue with nvidia 28x.xx series forceware driver, they use some dynamic clocking mechanism, they tweaked clocks performance states little sensitive after which it got all messed. Currently on nvidia forum, they are asking for cards from victimized people so they can reproduce the issue internally and fix it. So only hope for this bug is better nvidia driver or temporary fix (registry modification). TDR issue is very old but happening enormously with 28x.xx series driver.
For more info read this comment (3rd point): http://forums.nvidia.com/index.php?showtopic=213670&view=findpost&p=1316377 It maybe firmware issue but most probably driver issue. Problem is that it cause to crash firefox as well. You have to find workaround for it.
This continues to be the #1 graphics crash across all versions, and it's a null deref. Is there a bandaid fix we can attempt?
Sitting the #21 spot for crashes on 8.0 in the past week.
Keywords: topcrash
I just had a crash with this sig (bp-8e9f30f2-319d-4871-bffa-9f0dc2120103), and I have Intel processor graphics - is this bug bigger than nVidia cards or should I file a new bug? In fact many reports have non-nvidia gfx, eg: b23a4c31-04e2-497f-9689-dde452120103 9db922ed-4b8f-4e33-80b7-2b8592120103 8477f7ba-31a1-4e03-8a42-befa42111227 ... and this weird dual gfx but both are intel: 3a7844fa-3379-439c-b849-b0c8b2111227
It's #32 top browser crasher in 9.0.1, #21 in 10.0b5, #25 in 11.0a1 and #8 in 12.0a1 (because of 64-bit builds). In addition to the stack containing gfxSurfaceDrawable::Draw in comment 0, there's another one: Crashing Thread Frame Module Signature [Expand] Source 0 xul.dll _d2d_compute_bitmap_mem_size gfx/cairo/cairo/src/cairo-d2d-surface.cpp:1199 1 xul.dll _cairo_d2d_create_brush_for_pattern gfx/cairo/cairo/src/cairo-d2d-surface.cpp:2031 2 xul.dll _cairo_d2d_fill gfx/cairo/cairo/src/cairo-d2d-surface.cpp:3600 3 xul.dll _cairo_gstate_fill gfx/cairo/cairo/src/cairo-gstate.c:1295 4 xul.dll _moz_cairo_fill_preserve gfx/cairo/cairo/src/cairo.c:2459 5 xul.dll gfxWindowsNativeDrawing::PaintToContext gfx/thebes/gfxWindowsNativeDrawing.cpp:319 6 xul.dll nsNativeThemeWin::ClassicDrawWidgetBackground widget/windows/nsNativeThemeWin.cpp:3653 7 xul.dll nsNativeThemeWin::DrawWidgetBackground widget/windows/nsNativeThemeWin.cpp:1213 8 xul.dll nsCSSRendering::PaintBackgroundWithSC layout/base/nsCSSRendering.cpp:2312 9 xul.dll mozilla::FrameLayerBuilder::DrawThebesLayer layout/base/FrameLayerBuilder.cpp:2178 10 xul.dll mozilla::layers::ThebesLayerD3D10::DrawRegion gfx/layers/d3d10/ThebesLayerD3D10.cpp:425 11 xul.dll mozilla::layers::ThebesLayerD3D10::Validate gfx/layers/d3d10/ThebesLayerD3D10.cpp:287 12 xul.dll mozilla::layers::ContainerLayerD3D10::Validate gfx/layers/d3d10/ContainerLayerD3D10.cpp:380 13 xul.dll mozilla::layers::ContainerLayerD3D10::Validate gfx/layers/d3d10/ContainerLayerD3D10.cpp:382 14 xul.dll mozilla::layers::ContainerLayerD3D10::Validate gfx/layers/d3d10/ContainerLayerD3D10.cpp:382 15 xul.dll mozilla::layers::LayerManagerD3D10::Render gfx/layers/d3d10/LayerManagerD3D10.cpp:686 16 xul.dll mozilla::layers::LayerManagerD3D10::EndTransaction gfx/layers/d3d10/LayerManagerD3D10.cpp:355 17 xul.dll nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:637 18 xul.dll nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1807 ... More reports at: https://crash-stats.mozilla.com/report/list?signature=_d2d_compute_bitmap_mem_size
Summary: Crash in [@ _d2d_compute_bitmap_mem_size ] in Firefox 4 Beta 5 → Crash @ _d2d_compute_bitmap_mem_size
This is a bandaid fix as suggested by Joe. I think since we have no idea what causes the error this is the best, safest approach for now. In Azure we have a log system that we should probably try to somehow hookup to the crash reporter to harvest more data on these kind of events.
Attachment #593499 - Flags: review?(jmuizelaar)
Can you fin(In reply to Bas Schouten (:bas) from comment #19) > Created attachment 593499 [details] [diff] [review] > Fail brush creation when bitmap creation fails > > This is a bandaid fix as suggested by Joe. I think since we have no idea > what causes the error this is the best, safest approach for now. In Azure we > have a log system that we should probably try to somehow hookup to the crash > reporter to harvest more data on these kind of events. Can you file a bug or write a patch to hook this up?
(In reply to Jeff Muizelaar [:jrmuizel] from comment #20) > Can you fin(In reply to Bas Schouten (:bas) from comment #19) > > Created attachment 593499 [details] [diff] [review] > > Fail brush creation when bitmap creation fails > > > > This is a bandaid fix as suggested by Joe. I think since we have no idea > > what causes the error this is the best, safest approach for now. In Azure we > > have a log system that we should probably try to somehow hookup to the crash > > reporter to harvest more data on these kind of events. > > Can you file a bug or write a patch to hook this up? Filed bug 724775.
HWA disabled in thunderbird version 9, so no longer topcrash
Whiteboard: [newb5][tbird topcrash] → [newb5]
This is still in the top 30 crashes for 10.0.2.
jrmuizel, review ping?
Comment on attachment 593499 [details] [diff] [review] Fail brush creation when bitmap creation fails Review of attachment 593499 [details] [diff] [review]: ----------------------------------------------------------------- Sure.
Attachment #593499 - Flags: review?(jmuizelaar) → review+
Is this something we can land?
It's #25 top browser crasher in 11.0, #33 in 12.0b5, #23 in 13.0a2, and #26 in 14.0a1.
Bas, is there any reason not to land this?
There is not, anyone should feel free to land this, I can do it myself if need be too.
(In reply to Bas Schouten (:bas) from comment #29) > There is not, anyone should feel free to land this, I can do it myself if > need be too. Please go ahead and land it, its a top crash.
https://hg.mozilla.org/mozilla-central/rev/5648c9a38933
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
Let's get this nominated for Aurora too, so we can eliminate this topcrash there.
Comment on attachment 593499 [details] [diff] [review] Fail brush creation when bitmap creation fails [Approval Request Comment] Bug caused by (feature/regressing bug #): D2D User impact if declined: Crash Testing completed (on m-c, etc.): Yes Risk to taking this patch (and alternatives if risky): Very Low String or UUID changes made by this patch: None
Attachment #593499 - Flags: approval-mozilla-beta?
Attachment #593499 - Flags: approval-mozilla-aurora?
(In reply to Bas Schouten (:bas) from comment #34) > Risk to taking this patch (and alternatives if risky): Very Low Since this is being nominated for Beta, I'd like to better understand the risk here. What should we be on the lookout for in terms of regressions if we decide to take this fix?
Comment on attachment 593499 [details] [diff] [review] Fail brush creation when bitmap creation fails [Triage Comment] This has been a top crasher for a while, and we can't think of a scenario where checking FAILED(hr) and returning NULL could cause a new regression, so we're approving for both Aurora 14 and Beta 13.
Attachment #593499 - Flags: approval-mozilla-beta?
Attachment #593499 - Flags: approval-mozilla-beta+
Attachment #593499 - Flags: approval-mozilla-aurora?
Attachment #593499 - Flags: approval-mozilla-aurora+
Since we don't have a case which is reproducible to QA, can someone who was able to previously reproduce this crash please check if Firefox 13.0 Beta 6 or Firefox 14.0 Aurora 2012-05-29 reproduce this crash anymore? Thanks
Depends on: 759749
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: