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

the second heart seems to have no problems :shrug: the first one always does it

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

Milan, any idea who could help here? Thanks

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

The CreateWrappingDataSourceSurface path was relying on the gfxASurface outliving the DataSourceSurface, but nothing actually ensured that.

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.

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.

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

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?

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.

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.

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

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.

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/5636e18a27f5 for Windows unhappiness like https://tbpl.mozilla.org/php/getParsedLog.php?id=36975310&tree=Mozilla-Inbound

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.

Matt, Can we get an uplift request? Thanks!

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

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

https://hg.mozilla.org/releases/mozilla-aurora/rev/0717e2e53e18 https://hg.mozilla.org/releases/mozilla-beta/rev/94f17a84a883

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

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

Thanks Paul! Socorro also shows no crashes on builds post 03/31 (Firefox 29, 30, 31): https://crash-stats.mozilla.com/report/list?signature=atidxx32.dll%400x3f884a&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&version=Firefox%3A31.0a1&version=Firefox%3A30.0a2&version=Firefox%3A29.0b&hang_type=any&date=2014-04-16+07%3A00%3A00&range_value=4#tab-reports