603069 - [D2D] crash mainly at start-up on Windows 7 [@ HwTextFilter::PrepareFilterState(CD3DSurface*, CD3DSurface*, CD3DSurface*, DWRITE_RASTER_TYPE) ]

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Scoobidiver (away)]

Build: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101008 Firefox/4.0b8pre

This is a new crash signature. Crashes first appeared in b8pre/20101007 build.
It happens mainly at start-up on Windows 7.
It is #8 top crasher in b8pre/20101008 build.

Signature	HwTextFilter::PrepareFilterState(CD3DSurface*, CD3DSurface*, CD3DSurface*, DWRITE_RASTER_TYPE)
UUID	87b95bd0-16e9-427e-b6d2-a2d372101008
Time 	2010-10-08 06:16:02.584159
Uptime	1
Last Crash	1 seconds before submission
Install Age	30 seconds since version was first installed.
Product	Firefox
Version	4.0b8pre
Build ID	20101008041525
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_WRITE
Crash Address	0x90
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0191

Frame 	Module 	Signature [Expand] 	Source
0 	d2d1.dll 	HwTextFilter::PrepareFilterState 	
1 	d2d1.dll 	TextStageManager::CompleteRendering 	
2 	d2d1.dll 	CHwSurfaceRenderTarget::FlushQueuedOperations 	
3 	d2d1.dll 	CBatchSerializer::FlushInternal 	
4 	d2d1.dll 	CBatchSerializer::FlushInternalAndTryIncreaseStorage 	
5 	d2d1.dll 	DrawingContext::FillRectangle 	
6 	d2d1.dll 	D2DRenderTargetBase<ID2D1HwndRenderTarget>::FillRectangle 	
7 	xul.dll 	_cairo_d2d_fill 	gfx/cairo/cairo/src/cairo-d2d-surface.cpp:3386
8 	xul.dll 	_cairo_surface_fill 	gfx/cairo/cairo/src/cairo-surface.c:2216
9 	xul.dll 	_cairo_gstate_fill 	gfx/cairo/cairo/src/cairo-gstate.c:1184
10 	xul.dll 	_moz_cairo_fill_preserve 	gfx/cairo/cairo/src/cairo.c:2338
11 	xul.dll 	gfxSurfaceDrawable::Draw 	gfx/thebes/gfxDrawable.cpp:173
12 	xul.dll 	gfxUtils::DrawPixelSnapped 	gfx/thebes/gfxUtils.cpp:417
13 	xul.dll 	imgFrame::Draw 	modules/libpr0n/src/imgFrame.cpp:488
14 	xul.dll 	mozilla::imagelib::RasterImage::Draw 	modules/libpr0n/src/RasterImage.cpp:2432
15 	xul.dll 	DrawImageInternal 	layout/base/nsLayoutUtils.cpp:3068
16 	xul.dll 	nsLayoutUtils::DrawSingleImage 	layout/base/nsLayoutUtils.cpp:3185
17 	xul.dll 	nsImageBoxFrame::PaintImage 	layout/xul/base/src/nsImageBoxFrame.cpp:393
18 	xul.dll 	nsDisplayXULImage::Paint 	layout/xul/base/src/nsImageBoxFrame.cpp:343
19 	xul.dll 	mozilla::FrameLayerBuilder::DrawThebesLayer 	layout/base/FrameLayerBuilder.cpp:1684
20 	xul.dll 	mozilla::layers::ThebesLayerD3D9::DrawRegion 	gfx/layers/d3d9/ThebesLayerD3D9.cpp:345
21 	xul.dll 	mozilla::layers::ThebesLayerD3D9::RenderLayer 	gfx/layers/d3d9/ThebesLayerD3D9.cpp:223
22 	xul.dll 	mozilla::layers::ContainerLayerD3D9::RenderLayer 	gfx/layers/d3d9/ContainerLayerD3D9.cpp:218
23 	xul.dll 	mozilla::layers::LayerManagerD3D9::Render 	gfx/layers/d3d9/LayerManagerD3D9.cpp:290
24 	xul.dll 	mozilla::layers::LayerManagerD3D9::EndTransaction 	gfx/layers/d3d9/LayerManagerD3D9.cpp:158
25 	xul.dll 	nsDisplayList::PaintForFrame 	layout/base/nsDisplayList.cpp:452
26 	xul.dll 	nsLayoutUtils::PaintFrame 	layout/base/nsLayoutUtils.cpp:1429
27 	xul.dll 	PresShell::Paint 	layout/base/nsPresShell.cpp:6116
28 	xul.dll 	nsRegion::SubRect 	gfx/src/nsRegion.cpp:1111
29 	xul.dll 	nsViewManager::RenderViews 	view/src/nsViewManager.cpp:447

The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dee1e01fd8ed&tochange=5bb4f093a50b

More reports at:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=HwTextFilter%3A%3APrepareFilterState%28CD3DSurface*%2C%20CD3DSurface*%2C%20CD3DSurface*%2C%20DWRITE_RASTER_TYPE%29

Comment 1

[Bas Schouten (:bas.schouten)]

Hrm, so this started appearing the same time as Bug 603071. I wonder if there is some sort of correlation.

Comment 2

[Bas Schouten (:bas.schouten)]

So, this occurs when flushing the text rendering calls in the pipeline. Since the regression range contains a bunch of text rendering changes I'm wondering whether they could have something to do with this? Jfkthame, could you have a look at this?

Comment 3

[Bas Schouten (:bas.schouten)]

AdapterVendorID: 10de, AdapterDeviceID: 0191

This only appears to happen on this device, which is an NVidia 8800 GTX I believe.

Comment 4

[Jonathan Kew [:jfkthame]]

(In reply to comment #2)
> the regression range contains a bunch of text rendering changes I'm wondering
> whether they could have something to do with this?

The main font-related changes (apart from some Mac-only fixes) are the landing and integration of OTS, the sanitizer for downloadable fonts. I don't see how that could be a factor here.

The crash address is consistently 0x90, which sounds like it's probably related to a null pointer somewhere. Any possibility that the surface's RenderTarget or brush might not be valid?

Comment 5

[Bas Schouten (:bas.schouten)]

(In reply to comment #4)
> (In reply to comment #2)
> > the regression range contains a bunch of text rendering changes I'm wondering
> > whether they could have something to do with this?
> 
> The main font-related changes (apart from some Mac-only fixes) are the landing
> and integration of OTS, the sanitizer for downloadable fonts. I don't see how
> that could be a factor here.
> 
> The crash address is consistently 0x90, which sounds like it's probably related
> to a null pointer somewhere. Any possibility that the surface's RenderTarget or
> brush might not be valid?

Extremely unlikely, and nothing that touched any of that code in the regression range, fwiw. Could it be a font that gets sanitized in an improper way?

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to comment #5)
> Extremely unlikely, and nothing that touched any of that code in the regression
> range, fwiw. Could it be a font that gets sanitized in an improper way?

I don't thikn so. If so, it would probably not load the font at all - or crash within platform rasterizer code. This doesn't look at all like the font-related crashes we've seen in the past.

Copying jdaggett for any comments....

A testcase that reproduces the crash would be great, or even just a clue to the URLs where crashes are happening. With so many of them showing uptime=1, I wonder if they've even got as far as trying to load any downloadable fonts?

Comment 7

[Bas Schouten (:bas.schouten)]

(In reply to comment #6)
> (In reply to comment #5)
> > Extremely unlikely, and nothing that touched any of that code in the regression
> > range, fwiw. Could it be a font that gets sanitized in an improper way?
> 
> I don't thikn so. If so, it would probably not load the font at all - or crash
> within platform rasterizer code. This doesn't look at all like the font-related
> crashes we've seen in the past.
> 
> Copying jdaggett for any comments....
> 
> A testcase that reproduces the crash would be great, or even just a clue to the
> URLs where crashes are happening. With so many of them showing uptime=1, I
> wonder if they've even got as far as trying to load any downloadable fonts?

That's a good reason why it shouldn't be OTS. I'm surprised that it's all the exact same device though, I wonder if it's all the same user that has something broken?

Comment 8

[Scoobidiver (away)]

> I wonder if it's all the same user that has something broken?
There are two series of successive crashes, with same device id and same CPU, so there is only one user with this crash signature. So the regression range in comment 0 is not necessarily the good one.
I think it could be linked to the lastpass extension and its associated lpxpcom.dll file.

Comment 9

[Bas Schouten (:bas.schouten)]

(In reply to comment #8)
> > I wonder if it's all the same user that has something broken?
> There are two series of successive crashes, with same device id and same CPU,
> so there is only one user with this crash signature. So the regression range in
> comment 0 is not necessarily the good one.
> I think it could be linked to the lastpass extension and its associated
> lpxpcom.dll file.

Interesting, thanks for that information! In that case this is atleast blocking-!

Comment 10

[Scoobidiver (away)]

There have been only one crash in 8.0 for the last four weeks.

Comment 11

[Scoobidiver (away)]

There have been no crashes for the last four weeks.