crash in atidxx32.dll@0x3f884a, video hardware google doodle crash

VERIFIED FIXED in Firefox 29

Status

()

defect
--
critical
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: uranium23567, Assigned: mattwoodrow)

Tracking

({crash, regression})

29 Branch
mozilla31
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox28 unaffected, firefox29+ verified, firefox30+ verified, firefox31 verified)

Details

(crash signature)

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

5 years ago
The crash relates to a intel HD graphics x64 GD renderer. My hardware video is an ivy bridge i5 (4th Gen intel HD 4000 APU) with drivers 9.18.10.3165 (win7 x64). Not sure if it is a driver problem or  not, these drivers have given me no other problems. If you have a 4th (ivy bridge) or 3rd (sandy bridge) gen intel HD graphics, give it a try

go to the 2014 valentines day google doodle here:

http://www.google.com/doodles/valentines-day-2014-us

click on I think any heart and let it play, a few seconds later I get a crash

 Problem Event Name:	APPCRASH
  Application Name:	firefox.exe
  Application Version:	30.0.0.5159
  Application Timestamp:	52ff543c
  Fault Module Name:	igd10iumd64.dll
  Fault Module Version:	9.18.10.3165
  Fault Module Timestamp:	51899a19
  Exception Code:	c0000005
  Exception Offset:	000000000032a09d
  OS Version:	6.1.7601.2.1.0.256.48
  Locale ID:	1033
  Additional Information 1:	e4ab
  Additional Information 2:	e4ab358e1bee4923a29d1f2011909498
  Additional Information 3:	20ec
  Additional Information 4:	20ec8d9d666736e461c6dc22364bc833
Reporter

Comment 1

5 years ago
the second heart seems to have no problems :shrug:

the first one always does it

Comment 2

5 years ago
Crash sig: bp-29469f18-b242-4aaf-9c99-e0aa22140216


Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/cde32f9a08c8
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20131211130454
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/491765fa039c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 ID:20131211130645
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cde32f9a08c8&tochange=491765fa039c

Triggered by: Bug 948221
Blocks: 948221
Severity: trivial → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ atidxx32.dll@0x3f884a]
Component: General → Graphics
Ever confirmed: true
Keywords: crash, regression
Product: Firefox → Core
Summary: [nightlyx64] video hardware google doodle crash → crash in atidxx32.dll@0x3f884a, video hardware google doodle crash
Version: 30 Branch → 29 Branch
Milan, any idea who could help here? Thanks
Flags: needinfo?(milan)
Matt, any chance you can take a look?  It seems to be related to bug 948221 (Convert SurfaceFromElement to use Moz2D) that landed at the start of 29.  It would be nice to deal with it before 29 goes beta (3/17).
Assignee: nobody → matt.woodrow
Flags: needinfo?(milan) → needinfo?(matt.woodrow)
Assignee

Comment 6

5 years ago
The CreateWrappingDataSourceSurface path was relying on the gfxASurface outliving the DataSourceSurface, but nothing actually ensured that.
Attachment #8385116 - Flags: review?(bas)
Flags: needinfo?(matt.woodrow)
Comment on attachment 8385116 [details] [diff] [review]
Don't rely on surfaces staying alive long alive

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

I don't think the performance hit this is going to cause is acceptable. Can't we just make the SourceSurface keep the gfxASurface alive in this case? I realize there's a risk of cyclic references here so let's figure out how to address that and do that.
Attachment #8385116 - Flags: review?(bas) → review-
Assignee

Comment 8

5 years ago
How about this then?

We set user data pointing one direction or the other, depending on whether we're wrapping the data or created a new copy.
Attachment #8385815 - Flags: review?(bas)
Bas, could you review Matt patch? It would be nice if we could have the fix for 29 beta 4. (beta 3 being built today). Thanks
Flags: needinfo?(bas)
Comment on attachment 8385815 [details] [diff] [review]
Don't rely on surfaces staying alive long

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

::: gfx/thebes/gfxPlatform.cpp
@@ -814,5 @@
> -    if (!srcBuffer) {
> -      // We need to check if our gfxASurface will keep the underlying data
> -      // alive. This is true if gfxASurface actually -is- an ImageSurface or
> -      // if it is a gfxWindowsSurface which supports GetAsImageSurface.
> -      if (imgSurface != aSurface && !isWin32ImageSurf) {

I still feel like this patch will stop using a simple wrapping source surface when we have a Win32 image surface. That will probably cause some serious issues, am I missing something here Matt?
Flags: needinfo?(bas)
Flags: needinfo?(matt.woodrow)
Assignee

Comment 11

5 years ago
Comment on attachment 8385815 [details] [diff] [review]
Don't rely on surfaces staying alive long

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

::: gfx/thebes/gfxPlatform.cpp
@@ -814,5 @@
> -    if (!srcBuffer) {
> -      // We need to check if our gfxASurface will keep the underlying data
> -      // alive. This is true if gfxASurface actually -is- an ImageSurface or
> -      // if it is a gfxWindowsSurface which supports GetAsImageSurface.
> -      if (imgSurface != aSurface && !isWin32ImageSurf) {

Yes, this will still work fine.

For win32 image surfaces, GetAsImageSurface() will return a valid result for imgSurface will be non-null, and copy will be null.

Then, if CreateSourceSurfaceFromData fails, we take the CreateWrappingDataSourceSurface path below.
Assignee

Updated

5 years ago
Flags: needinfo?(matt.woodrow)
Comment on attachment 8385815 [details] [diff] [review]
Don't rely on surfaces staying alive long

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

I think this'll work, but it's pretty tedious code.
Attachment #8385815 - Flags: review?(bas) → review+

Comment 13

5 years ago
Your Intel drivers are pretty old, you should update to the latest Intel 10.18.10.3496 drivers and see if this fixes it.

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23714
Assignee

Updated

5 years ago
Attachment #8385116 - Attachment is obsolete: true
Assignee

Comment 14

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/5adc1acdb309

Drivers versions are unlikely to make a difference, this bug is triggered by trying to use a surface bigger than the maximum texture size. That's probably going to be fixed for the GPU, not dependent on drivers.
Looks like the Windows browser-chrome failure that I thought wasn't from this actually was, though it wound up varying between social/browser_share.js and browser_dbg_variables-view-popup-05.js hanging.
https://hg.mozilla.org/mozilla-central/rev/effea5af03b6
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Matt, Can we get an uplift request? Thanks!
Flags: needinfo?(matt.woodrow)
Assignee

Comment 20

5 years ago
Comment on attachment 8385815 [details] [diff] [review]
Don't rely on surfaces staying alive long

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 948221
User impact if declined: Crash on some websites with integrated GPU's.
Testing completed (on m-c, etc.): Been on m-c for a while, manual tested.
Risk to taking this patch (and alternatives if risky): Low risk
String or IDL/UUID changes made by this patch: None
Attachment #8385815 - Flags: approval-mozilla-beta?
Attachment #8385815 - Flags: approval-mozilla-aurora?
Flags: needinfo?(matt.woodrow)
Comment on attachment 8385815 [details] [diff] [review]
Don't rely on surfaces staying alive long

Thanks
Attachment #8385815 - Flags: approval-mozilla-beta?
Attachment #8385815 - Flags: approval-mozilla-beta+
Attachment #8385815 - Flags: approval-mozilla-aurora?
Attachment #8385815 - Flags: approval-mozilla-aurora+

Comment 23

5 years ago
I have an Intel HD 4000 with the driver version: 9.17.10.2932 (it says the driver's up-to-date). I tried to reproduce this issue on Windows 7 64-bit on this machine, using Firefox 29.0b3, but didn't manage to get one crash.

Paul, can you please verify that this issue is no longer reproducing for you on the versions where it was fixed?
(The fix for Firefox 29 will only be on beta 5, which only appears tomorrow:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/29.0b5-candidates/build1/)

Updated

5 years ago
Flags: needinfo?(uranium23567)
Reporter

Comment 24

5 years ago
sorry i didn't see the email till now. I updated to nightly v31 and it cleared it up. Good job everyone

-p
Flags: needinfo?(uranium23567)

Updated

5 years ago
Duplicate of this bug: 988548
You need to log in before you can comment on or make changes to this bug.