Closed Bug 594779 Opened 14 years ago Closed 14 years ago

[D3D9] crash [@ mozilla::layers::ThebesLayerD3D9::DrawRegion(nsIntRegion const&) ]

Categories

(Core :: Graphics, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: scoobidiver, Assigned: bas.schouten)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

Build : Mozilla/5.0 (Windows NT 5.1.2600 Service Pack 3; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre

It is #17 top crasher for the last week.
Since 20100905 build (D3D9 ON by default), the daily rate is about 15 crashes/day. It happened sometimes before 09/05, probably with layers.accelerate-all set manually to true.
It occurs mainly on Windows XP.
One comment says it was on allsp.com.

Signature	mozilla::layers::ThebesLayerD3D9::DrawRegion(nsIntRegion const&)
UUID	c1e47533-9aa9-40fd-87ac-e3eff2100908
Time 	2010-09-08 10:47:01.472764
Uptime	11805
Last Crash	653180 seconds (1.1 weeks) before submission
Install Age	50344 seconds (14.0 hours) since version was first installed.
Product	Firefox
Version	4.0b6pre
Build ID	20100907041859
Branch	2.0
OS	Windows NT
OS Version	5.1.2600 Service Pack 2
CPU	x86
CPU Info	AuthenticAMD family 15 model 47 stepping 0
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x0
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0141

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	mozilla::layers::ThebesLayerD3D9::DrawRegion 	gfx/layers/d3d9/ThebesLayerD3D9.cpp:386
1 	xul.dll 	mozilla::layers::ThebesLayerD3D9::RenderLayer 	gfx/layers/d3d9/ThebesLayerD3D9.cpp:213
2 	xul.dll 	mozilla::layers::ContainerLayerD3D9::RenderLayer 	gfx/layers/d3d9/ContainerLayerD3D9.cpp:220
3 	xul.dll 	mozilla::layers::LayerManagerD3D9::Render 	gfx/layers/d3d9/LayerManagerD3D9.cpp:218
4 	xul.dll 	mozilla::layers::LayerManagerD3D9::EndTransaction 	gfx/layers/d3d9/LayerManagerD3D9.cpp:131
5 	xul.dll 	nsDisplayList::PaintForFrame 	layout/base/nsDisplayList.cpp:418
6 	xul.dll 	nsLayoutUtils::PaintFrame 	layout/base/nsLayoutUtils.cpp:1412
7 	xul.dll 	PresShell::Paint 	layout/base/nsPresShell.cpp:5934
8 	xul.dll 	nsViewManager::RenderViews 	view/src/nsViewManager.cpp:459
9 	xul.dll 	nsViewManager::Refresh 	view/src/nsViewManager.cpp:425
10 	xul.dll 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:940
11 	xul.dll 	AttachedHandleEvent 	view/src/nsView.cpp:193
12 	xul.dll 	nsWindow::DispatchEvent 	widget/src/windows/nsWindow.cpp:3534
13 	xul.dll 	nsWindow::DispatchWindowEvent 	widget/src/windows/nsWindow.cpp:3565
14 		@0x12d6f7 	

More reports at :
http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&date=2010-09-09%2005%3A00%3A00&signature=mozilla%3A%3Alayers%3A%3AThebesLayerD3D9%3A%3ADrawRegion%28nsIntRegion%20const%26%29&version=Firefox%3A4.0b6pre
blocking2.0: --- → ?
moved up to #10 on 4.0b7pre and a bit of a spike with recent builds. we should consider blocking on this.


date     tl crashes at, count build, count build, ...
         mozilla::layers::ThebesLayerD3D9::DrawRegion.nsIntRegion.const..
20100910 40 ,, 18 4.0b6pre2010090904, 16 4.0b6pre2010091004, 
                3 4.0b6pre2010090704, 2 4.0b6pre2010090804, 1 4.0b52010083108, 
20100911 15 ,, 13 4.0b6pre2010091004, 1 4.0b6pre2010091104, 
                1 4.0b6pre2010090904, 
20100912 22 ,, 19 4.0b6pre2010091104, 2 4.0b6pre2010091204, 
                1 4.0b6pre2010090704, 
20100913 35 ,, 20 4.0b6pre2010091304, 7 4.0b6pre2010091104, 
                5 4.0b6pre2010090904, 3 4.0b6pre2010091204, 
20100914 31 ,, 12 4.0b6pre2010091204, 11 4.0b6pre2010091304, 
                4 4.0b6pre2010090904, 2 4.0b7pre2010091404, 
                2 4.0b6pre2010091104, 
20100915 10 ,, 8 4.0b7pre2010091404, 1 4.0b6pre2010091404, 
               1 4.0b6pre2010090804, 
20100916 9 ,, 4 4.0b7pre2010091507, 3 4.0b7pre2010091604, 
              2 4.0b7pre2010091404, 
20100917 21 ,, 7 4.0b6pre2010091704, 5 4.0b7pre2010091604, 
               3 4.0b7pre2010091704, 2 4.0b6pre2010091004, 
               2 4.0b6pre2010090904, 1 4.0b7pre2010091507, 
               1 4.0b6pre2010090604, 
20100918 12 ,, 7 4.0b7pre2010091704, 3 4.0b7pre2010091804, 
               1 4.0b7pre2010091604, 1 4.0b6pre2010091704, 
20100919 18 ,, 8 4.0b7pre2010091604, 6 4.0b7pre2010091804, 
               3 4.0b6pre2010091304, 1 4.0b7pre2010091704, 
20100920 32 ,, 15 4.0b7pre2010092004, 7 4.0b6pre2010092004, 
                4 4.0b7pre2010091904, 3 4.0b7pre2010091804, 
                1 4.0b7pre2010091704, 1 4.0b7pre2010091404, 
                1 4.0b6pre2010091304, 
20100921 36 ,, 24 4.0b7pre2010092104, 12 4.0b7pre2010092004, 
20100922 31 ,, 30 4.0b7pre2010092104, 1 4.0b7pre2010092004, 

os breakdown
mozilla::layers::ThebesLayerD3D9::DrawRegion.nsIntRegion.const..Total 31
Win5.1  0.94
Win6.0  0.00
Win6.1  0.06

Correlation to startup or time of session and urls indicate this is mostly close to start up.

31 total crashes for mozilla::layers::ThebesLayerD3D9::DrawRegion.nsIntRegion.const.. on 20100922-crashdata.csv
22 startup crashes inside 30 sec.
23 startup crashes inside 3 min.

urls for testing
  13 jar:file:///C:/Program%20Files/Minefield/omni.jar!/chrome/browser/content/browser/aboutHome.xhtml
   9 jar:file:///C:/Program%20Files/Minefield/omni.jar!/chrome/browser/content/browser/aboutSessionRestore.xhtml
   1 http://forum.asterios.tm/index.php?showtopic=34251&view=&hl=%D0%B3%D0%B0%D0%B9%D0%B4%20%D0%BF%D0%BE%20%D1%82%D1%85&fromsearch=1
   1 http://en.wikipedia.org/wiki/Category:Maltese_football_clubs
   1 http://allegro.pl/show_user_auctions.php?uid=17234646&p=1
and some adult video sites
STR:
1 - Open a new blank window 
2 - Maximize it
3 - Open many blank windows (about:blank), at least 20 of them
4 - (all blank windows should be maximized)
5 - Move the mouse pointer over the title bar of the last window opened
6 - Double click as fast as you can to un-maximize all the windows opened in step 3
RESULT:
At some point, firfox freezes and the crash reporter pops up
REMARKS:
May happen on session restore when a lot of windows are restored
I can't reproduce this issue. Theoretically this patch should prevent the crash from occurring, but it could lead to some drawing artifacts. In theory however unless things are considerably messed up it should recover, so this patch is probably a good idea anyway.
Assignee: nobody → bas.schouten
Status: NEW → ASSIGNED
Attachment #478662 - Flags: review?(vladimir)
I've just found slimper steps to reproduce:

1 - Open a new blank window 
2 - Maximize it
3 - Open a new blank window, wait until it has displayed (2 seconds)
4 - Repeat step 3

RESULT:
I can't create more than 5 maximized blank windows, firefox would crash when trying to create the sixth window

REMARKS:
Only happens with maximized windows. Doesn't happen with tabs.
The fifth new blank window is created but does not paint, then moving this window around gives artifacts. Other windows doesn't seem to be affected, though. It seems that system resources are exhausted. Using NVIDIA NVS 280 PCI-E video card with 64MB memory.

Could it be possible to detect this situation on window creation and fallback to unaccelerated rendering, on a per-window basis ?
(In reply to comment #4)
> I've just found slimper steps to reproduce:
> 
> 1 - Open a new blank window 
> 2 - Maximize it
> 3 - Open a new blank window, wait until it has displayed (2 seconds)
> 4 - Repeat step 3
> 
> RESULT:
> I can't create more than 5 maximized blank windows, firefox would crash when
> trying to create the sixth window
> 
> REMARKS:
> Only happens with maximized windows. Doesn't happen with tabs.
> The fifth new blank window is created but does not paint, then moving this
> window around gives artifacts. Other windows doesn't seem to be affected,
> though. It seems that system resources are exhausted. Using NVIDIA NVS 280
> PCI-E video card with 64MB memory.
> 
> Could it be possible to detect this situation on window creation and fallback
> to unaccelerated rendering, on a per-window basis ?

It's not really in the codepath for window creation but in the codepath for painting, so this is quite tricky. I'm assuming you're somehow running out of video memory but I don't see how that would happen for so few windows. It might be something about your drivers, it's possible we'd be better off using D3DCREATE_DISABLE_DRIVER_MANAGEMENT to ensure we get consistent resource management. But on the other hand I'd expect that to have a negative performance impact.
(In reply to comment #4)
> I've just found slimper steps to reproduce:
> 
> 1 - Open a new blank window 
> 2 - Maximize it
> 3 - Open a new blank window, wait until it has displayed (2 seconds)
> 4 - Repeat step 3
> 
> RESULT:
> I can't create more than 5 maximized blank windows, firefox would crash when
> trying to create the sixth window

I tried this until about 50 windows at which point I gave up. So considering this might be VRAM it's possible we should consider evicting resources for windows which aren't currently visible. This'll require some thought though, for now I'll land this patch, it's possible you'll be seeing some drawing artifacts after it did, please let us know about them, and their behavior!
http://hg.mozilla.org/mozilla-central/rev/6272ce1da6f5
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
I'm still seeing this!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Never mind, crashes I saw were on the tracemonkey branch.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Crashes are still there.
It is #20 top crasher in b7pre build for the last week.

More reports at :
http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=mozilla%3A%3Alayers%3A%3AThebesLayerD3D9%3A%3ADrawRegion%28nsIntRegion%20const%26%29&version=Firefox%3A4.0b7pre
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #10)
> Crashes are still there.
> It is #20 top crasher in b7pre build for the last week.
> 
> More reports at :
> http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=mozilla%3A%3Alayers%3A%3AThebesLayerD3D9%3A%3ADrawRegion%28nsIntRegion%20const%26%29&version=Firefox%3A4.0b7pre

As far as I can see those are all builds from before this patch, please reopen if you can point me at a crash in a build from after this patch, maybe I'm missing something.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Bas,
The patch was landed on b7pre/20100928 build.
If you sort out the reports by build id, you can see it still crashes with b7pre/20101002 build. Here below is a crash id with this build :
7d56f8d2-a20e-40b3-ae54-9d22e2101002.
So it is not fixed.
(In reply to comment #12)
> Bas,
> The patch was landed on b7pre/20100928 build.
> If you sort out the reports by build id, you can see it still crashes with
> b7pre/20101002 build. Here below is a crash id with this build :
> 7d56f8d2-a20e-40b3-ae54-9d22e2101002.
> So it is not fixed.

Ah, yes! Note that is a different crash though than this bug. Same function, different line, I'll fix it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The crash this bug is about is fixed.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Crash Signature: [@ mozilla::layers::ThebesLayerD3D9::DrawRegion(nsIntRegion const&) ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: