595375 - Crash @ _d2d_compute_bitmap_mem_size

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Marcia Knous [:marcia]]

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

Comment 1

[chris hofmann]

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

Comment 2

[chris hofmann]

more at http://crash-stats.mozilla.com/report/list?signature=_d2d_compute_bitmap_mem_size

all the crash addresses appear to be  0x0

Comment 3

[Wayne Mery (:wsmwk)]

> 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

Comment 4

[Wayne Mery (:wsmwk)]

#22 crash for Tbird v6. Estimate 80 reporters for 4 weeks.

Comment 5

[Wayne Mery (:wsmwk)]

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)

Comment 6

[Alexander Anding]

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.

Comment 7

[Wayne Mery (:wsmwk)]

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!)

Comment 8

[Emanuel Hoogeveen [:ehoogeveen]]

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.

Comment 9

[Ahmad Saleem]

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.

Comment 10

[Ahmad Saleem]

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.

Comment 11

[Wayne Mery (:wsmwk)]

Bas, does the above information help you in any way?

Comment 12

[Bas Schouten (:bas.schouten)]

Nothing obvious, but I'll look some more.

Comment 13

[Ahmad Saleem]

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.

Comment 14

[Ahmad Saleem]

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.

Comment 15

[Joe Drew (not getting mail)]

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?

Comment 16

[Sheila Mooney]

Sitting the #21 spot for crashes on 8.0 in the past week.

Comment 17

[James May [:fowl2]]

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

Comment 18

[Scoobidiver (away)]

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

Comment 19

[Bas Schouten (:bas.schouten)]

Attachment: 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.

Comment 20

[Jeff Muizelaar [:jrmuizel]]

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?

Comment 21

[Bas Schouten (:bas.schouten)]

(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.

Comment 22

[Wayne Mery (:wsmwk)]

HWA disabled in thunderbird version 9, so no longer topcrash

Comment 23

[Sheila Mooney]

This is still in the top 30 crashes for 10.0.2.

Comment 24

[Bas Schouten (:bas.schouten)]

jrmuizel, review ping?

Comment 25

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 593499 [details] [diff] [review]
Fail brush creation when bitmap creation fails

Review of attachment 593499 [details] [diff] [review]:
-----------------------------------------------------------------

Sure.

Comment 26

[Sheila Mooney]

Is this something we can land?

Comment 27

[Scoobidiver (away)]

It's #25 top browser crasher in 11.0, #33 in 12.0b5, #23 in 13.0a2, and #26 in 14.0a1.

Comment 28

[JP Rosevear [:jpr]]

Bas, is there any reason not to land this?

Comment 29

[Bas Schouten (:bas.schouten)]

There is not, anyone should feel free to land this, I can do it myself if need be too.

Comment 30

[JP Rosevear [:jpr]]

(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.

Comment 31

[Bas Schouten (:bas.schouten)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5648c9a38933

Comment 32

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/5648c9a38933

Comment 33

[Lukas Blakk [:lsblakk] use ?needinfo]

Let's get this nominated for Aurora too, so we can eliminate this topcrash there.

Comment 34

[Bas Schouten (:bas.schouten)]

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

Comment 35

[Alex Keybl [:akeybl]]

(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 36

[Alex Keybl [:akeybl]]

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.

Comment 37

[Joe Drew (not getting mail)]

http://hg.mozilla.org/releases/mozilla-aurora/rev/ef414707a0d6
http://hg.mozilla.org/releases/mozilla-beta/rev/d9fb1d760f51

Comment 38

[u279076]

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