Crash in gfxASurface::Release() mainly at startup

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
7 years ago
3 years ago

People

(Reporter: scoobidiver, Assigned: jrmuizel)

Tracking

({crash})

Trunk
x86
Windows 7
crash
Points:
---

Firefox Tracking Flags

(firefox9+, firefox10+, firefox11+ wontfix, firefox12-)

Details

(Whiteboard: startupcrash, crash signature)

(Reporter)

Description

7 years ago
It's #67 top crasher in 9.0b2.

Signature	gfxASurface::Release()
UUID	c7292b86-f2c2-4cdc-a72e-35d662111122
Date Processed	2011-11-22 22:21:45.627980
Uptime	3
Last Crash	6.9 weeks before submission
Install Age	2.8 minutes since version was first installed.
Install Time	2011-11-23 06:18:44
Product	Firefox
Version	11.0a1
Build ID	20111122030949
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 15 stepping 13
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x12
App Notes 	AdapterVendorID: 8086, AdapterDeviceID: 2a02, AdapterSubsysID: 00000000, AdapterDriverVersion: 8.15.10.1930
D3D10 Layers? D3D10 Layers-
D3D9 Layers? D3D9 Layers+
EMCheckCompatibility	True

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	gfxASurface::Release 	gfx/thebes/gfxASurface.cpp:124
1 	xul.dll 	gfxContext::`scalar deleting destructor' 	
2 	xul.dll 	gfxContext::Release 	obj-firefox/dist/include/gfxContext.h:71
3 	xul.dll 	nsWindow::OnPaint 	widget/src/windows/nsWindowGfx.cpp:447
4 	xul.dll 	nsWindow::ProcessMessage 	widget/src/windows/nsWindow.cpp:4902
5 	xul.dll 	nsWindow::WindowProcInternal 	widget/src/windows/nsWindow.cpp:4470
6 	xul.dll 	CallWindowProcCrashProtected 	xpcom/base/nsCrashOnException.cpp:65
7 	xul.dll 	nsWindow::WindowProc 	widget/src/windows/nsWindow.cpp:4412
...

More crash reports at:
https://crash-stats.mozilla.com/report/list?signature=gfxASurface%3A%3ARelease%28%29
(Reporter)

Comment 1

7 years ago
It's #8 top crasher in 9.0b2.
tracking-firefox9: --- → ?
Jeff, I think it makes the most sense for you to look at this bug.
Duplicate of this bug: 712931
The reporter in Bug 712931 seems to have STR which involve using the run command on Windows 7.

Updated

7 years ago
tracking-firefox10: --- → ?
tracking-firefox11: --- → ?
tracking-firefox12: --- → ?
Keywords: qawanted, testcase-wanted

Updated

7 years ago
tracking-firefox10: ? → +
tracking-firefox11: ? → +
tracking-firefox12: ? → +
tracking-firefox9: ? → -

Updated

7 years ago
tracking-firefox9: - → +

Updated

7 years ago
Keywords: topcrash
Whiteboard: startupcrash

Comment 5

7 years ago
Jeff, have you had a chance to look at this?
(Assignee)

Comment 6

7 years ago
It seems like this is only happening on D3D9. I looked at 4 crashes and they all had:

D3D10 Layers? D3D10 Layers-
D3D9 Layers? D3D9 Layers+

Is there away that we can run queries on the App Notes to confirm this?
(Assignee)

Updated

7 years ago
Summary: Crash in gfxASurface::Release() mainly at startup → Crash in gfxASurface::Release() mainly at startup on D3D9 layers?

Comment 7

7 years ago
Probably, let me look into this.

Comment 8

7 years ago
Hey Jeff - seems like you're doing the engineering investigation of this bug, so I'm assigning it to you. We're trying to make sure that no tracked bugs are left unassigned. Thanks!
Assignee: nobody → jmuizelaar

Comment 9

7 years ago
Kairo, is there a way to easily run a report on the app notes field for all crashes and see if they contain what Jeff listed in comment#6.

Comment 10

7 years ago
(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)
> It seems like this is only happening on D3D9. I looked at 4 crashes and they
> all had:
> 
> D3D10 Layers? D3D10 Layers-
> D3D9 Layers? D3D9 Layers+
> 
> Is there away that we can run queries on the App Notes to confirm this?

I ran the following command on a single CSV file (yesterday's) from https://crash-analysis.mozilla.com/crash_analysis/ (so this gives you the D2D/D3D parts of the app notes, summed up by frequency):

$ gunzip --stdout /mnt/crashanalysis/crash_analysis/20120118/*-pub-crashdata.csv.gz | awk '-F\t' '$1 ~ /^gfxASurface::Release/ {match($26, /(D[23]D.+)/, arr); printf "%s;\n",arr[1]}' | sort | uniq -c | sort -nr     90 D3D10 Layers? D3D10 Layers- | D3D9 Layers? D3D9 Layers-;

     71 D2D? D2D- | D3D10 Layers? D3D10 Layers- | D3D9 Layers? D3D9 Layers+;
     58 D3D10 Layers? D3D10 Layers- | D3D9 Layers? D3D9 Layers+;
      4 D3D10 Layers? D3D10 Layers-;
      3 D2D? D2D+ | DWrite? DWrite+ | D3D10 Layers? D3D10 Layers+;
      2 D3D10 Layers? D3D10 Layers- | D3D9 Layers? D3D9 Layers- | WebGL? WebGL-;
      1 D3D10 Layers? D3D10 Layers- | D3D9 Layers? D3D9 Layers+ | WebGL? EGL? EGL+ | GL Context? GL Context+ | WebGL+;
      1 ;

At least it looks like the majority of those crashes has D3D9 and not D3D10, but for a couple that's different. My awk script may not be perfect, but you can analyze a CSV yourself if you like and if that can give you more data. I can also run some more commands. I pasted what I used here because I don't think I'd remember it myself. ;-)
(Assignee)

Comment 11

7 years ago
90 D3D10 Layers? D3D10 Layers- | D3D9 Layers? D3D9 Layers-;

This suggest that most of the crashes don't have any D3D, 9 or 10.
Summary: Crash in gfxASurface::Release() mainly at startup on D3D9 layers? → Crash in gfxASurface::Release() mainly at startup
(Assignee)

Comment 12

7 years ago
Looking at the disassembly in these crashes the mSurface pointer is mostly 2. I have no idea why that would be.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #12)
> Looking at the disassembly in these crashes the mSurface pointer is mostly
> 2. I have no idea why that would be.

Is there anything more that we can pull from the crash info to aid you in your investigation? Please let us know if user outreach would also be helpful. Thanks!

Comment 14

7 years ago
This is sitting at #95 on 11b3 with 82 crashes. It can probably be removed from the tracking list but it is a startup crash so it would be good to try and make progress if there is anything further that we can do. Jeff, is there anything more we can pull from the crash reports that might help?

Comment 15

7 years ago
Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120223 Firefox/13.0a1
Mozilla/5.0 (Windows NT 6.1; rv:12.0a2) Gecko/20120223 Firefox/12.0a2
Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0

I tried to reproduce this issue using the steps from bug #712931 (both with the given link and the updated testcase) but everything worked fine.

Does anyone have any other STR or at least some guidelines for reproducing this issue?

Updated

7 years ago
tracking-firefox11: + → -
tracking-firefox12: + → -
Keywords: topcrash
Removing qawanted since we've been unable to reproduce and this is no longer a top crash, nor is it being tracked. Please re-add qawanted if there is something more you want QA to do.
Keywords: qawanted
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #16)
> Removing qawanted since we've been unable to reproduce and this is no longer
> a top crash, nor is it being tracked. Please re-add qawanted if there is
> something more you want QA to do.

Also wontfixing for FF11 and untracking for FF12 since this is across multiple versions of Firefox and we have no reason to believe that this is any worse in FF11 at this point.
status-firefox11: --- → wontfix
tracking-firefox11: - → +
Keywords: topcrash
(Reporter)

Comment 18

6 years ago
There are 71 crashes in 13.0.
Keywords: topcrash
(Reporter)

Comment 19

6 years ago
There are 61 crashes in 17.0.1 and 11 in 18.0b4 so no need to have a bug opened for that.
For 19.0 and above, bug 822999 is filed for that
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.