668344 - crash _cairo_d2d_surface_init

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This bug was filed from the Socorro interface and is 
report bp-7503175d-6152-43a2-abce-f3a942110629 .
============================================================= 

I triggered the crash with the following steps
 (1) Load pdf.js with d2d enabled.  (I loaded latest trunk, but [1] ought not to be different wrt this bug.)
 (2) Disable d2d in Options menu
 (3) Ctrl-r to reload

I haven't tried to repro.

[1] http://andreasgal.github.com/pdf.js/multi-page-viewer.html#1

Comment 1

[adminnu]

Comments

Panorama click item

Submitted: 2011-07-08 00:23:41-07

Comment 2

[adminnu]

https://crash-stats.mozilla.com/report/index/bp-9f5bb4a1-de1b-4067-82af-0ad222110708

Comment 3

[Robert Kaiser]

This has now risen up on all versions, see https://crash-stats.mozilla.com/report/list?signature=_cairo_d2d_surface_init%28_cairo_d2d_surface*%2C%20_cairo_d2d_device*%2C%20_cairo_format%29

Comment 4

[Bas Schouten (:bas.schouten)]

We should really start forcing a reboot after switching D2D on/off. But I guess we could still end up in a situation where it is unusable after a driver uninstall or something. I wonder what we should do about it.

Comment 5

[Bas Schouten (:bas.schouten)]

(In reply to Bas Schouten (:bas) from comment #4)
> We should really start forcing a reboot after switching D2D on/off. But I
> guess we could still end up in a situation where it is unusable after a
> driver uninstall or something. I wonder what we should do about it.

I meant restart, obviously.

Comment 6

[Bas Schouten (:bas.schouten)]

Attachment: Deal with Direct2D device going missing in Azure.

This bug deals with the Direct2D device going AWOL for Azure surfaces. The behavior is now similar (i.e. the canvas becomes white/invisible) as without Azure.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

(In reply to Bas Schouten (:bas) from comment #6)
> Created attachment 569701 [details] [diff] [review] [diff] [details] [review]
> Deal with Direct2D device going missing in Azure.
> 
> This bug deals with the Direct2D device going AWOL for Azure surfaces. The
> behavior is now similar (i.e. the canvas becomes white/invisible) as without
> Azure.

Can we test for this? i.e. Force device lost and make sure things don't blow up?

Comment 8

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 569701 [details] [diff] [review]
Deal with Direct2D device going missing in Azure.

I'm not really thrilled with this patch. It feels a bit like "avoid the crash" instead of prevent it. Can you sell me on it better?

Comment 9

[Bas Schouten (:bas.schouten)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #7)
> (In reply to Bas Schouten (:bas) from comment #6)
> > Created attachment 569701 [details] [diff] [review] [diff] [details] [review] [diff] [details] [review]
> > Deal with Direct2D device going missing in Azure.
> > 
> > This bug deals with the Direct2D device going AWOL for Azure surfaces. The
> > behavior is now similar (i.e. the canvas becomes white/invisible) as without
> > Azure.
> 
> Can we test for this? i.e. Force device lost and make sure things don't blow
> up?

I don't think we can but I'm open to suggestions, the Firefox process can't do it anyway, you'd need something privileged.

If the Firefox process did it (for example by a shader that hangs the GPU) it would be recovered and get D3D10/D2D again. Also a nasty situation, but different from this one where we switch back to basic layers.

Comment 10

[[:Cww]]

This can ride the trains for now, isn't release specific and there's no way this patch (even if it is the correct one) will make it in Firefox 8.  Ask for approval if warranted when you have a patch.

Comment 11

[Robert Kaiser]

(In reply to [:Cww] from comment #10)
> This can ride the trains for now, isn't release specific and there's no way
> this patch (even if it is the correct one) will make it in Firefox 8.

Unfortunately this crash is still rising on 8, it's topcrash #30 on 8.0b4 in the last 3 days.

Comment 12

[Bas Schouten (:bas.schouten)]

(In reply to Robert Kaiser (:[e-mail]) from comment #11)
> (In reply to [:Cww] from comment #10)
> > This can ride the trains for now, isn't release specific and there's no way
> > this patch (even if it is the correct one) will make it in Firefox 8.
> 
> Unfortunately this crash is still rising on 8, it's topcrash #30 on 8.0b4 in
> the last 3 days.

I wonder what's happening that trigger's this rise. It shouldn't be too common for people to be using Canvas and then switching off hardware acceleration while using it. Unless there's a lot of people doing performance comparisons or something.

Comment 13

[Robert Kaiser]

(In reply to Bas Schouten (:bas) from comment #12)
> I wonder what's happening that trigger's this rise.

The comments in the page linked in comment #3 suggest that it happens for some of those people when a graphics driver is updating, others seem to not know a reason, just changing tabs or stuff like that, others mention that they disabled graphics acceleration.

Comment 14

[Bas Schouten (:bas.schouten)]

(In reply to Robert Kaiser (:[e-mail]) from comment #13)
> (In reply to Bas Schouten (:bas) from comment #12)
> > I wonder what's happening that trigger's this rise.
> 
> The comments in the page linked in comment #3 suggest that it happens for
> some of those people when a graphics driver is updating, others seem to not
> know a reason, just changing tabs or stuff like that, others mention that
> they disabled graphics acceleration.

Yeah, a driver update would certainly do it. I'm not sure why the frequency of those would increase though!

Jeff, could you reply to my comments here? :) Or r+ of course.

Comment 15

[Robert Kaiser]

This has been spiking in yesterday's trunk data, is the patch here something to go forward with? Or is the spike related to bug 704143?

Comment 16

[Sheila Mooney]

I am going to add the top crash keyword since it seems to have spiked up. If it goes down, we can remove it.

Comment 17

[Scoobidiver (away)]

It's #17 top browser crasher in 11.0a2 and #44 in 12.0a1.

Comment 18

[Scoobidiver (away)]

It's #5 top crasher in 11.0b1.

Comment 19

[Alex Keybl [:akeybl]]

Top crasher in FF11, rising since FF8, tracking.

Comment 20

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 569701 [details] [diff] [review]
Deal with Direct2D device going missing in Azure.

ok... Crashes are bad.

Comment 21

[Bas Schouten (:bas.schouten)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0b14a07b9ac4

Comment 22

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/0b14a07b9ac4

Comment 23

[Alex Keybl [:akeybl]]

If this topcrash fix is sufficiently low-risk for Aurora/Beta consideration, please nominate. Thanks!

Comment 24

[Lukas Blakk [:lsblakk] use ?needinfo]

[Triage Comment]
What's the risk assessment for this? Is there a nomination coming for Aurora/Beta?

Comment 25

[Scoobidiver (away)]

Crashes are gone after 12.0a1/20120117, so before the patch landed:
https://crash-stats.mozilla.com/report/list?query_search=signature&query_type=contains&reason_type=contains&date=2012-01-31&version=Firefox:12.0a1&range_value=4&range_unit=weeks&hang_type=any&process_type=any&signature=_cairo_d2d_surface_init%28_cairo_d2d_surface*%2C%20_cairo_d2d_device*%2C%20_cairo_format%29

The working window is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=34572943a3e4&tochange=f4049f65efc6
There is a bunch of graphic bugs in it. It's hard to determine which one has fixed this bug.

Comment 26

[Sheila Mooney]

So if we don't know what fixed this then we can't really do anything on aurora and beta. I guess we let it ride the trains? Should we untrack it?

Comment 27

[Alex Keybl [:akeybl]]

I've sent email to Bas about whether we should consider fixing for FF11.

Comment 28

[Bas Schouten (:bas.schouten)]

Jeff, a lot of those graphics patches are yours, any idea which might've accidentally adressed this issue if Scoobidiver is correct?

Possibly that we're now getting the old, stored ThebesSurface and no longer trying to create one? (i.e. it's not actually giving a working surface, just not creating a broken one)

Comment 29

[Bas Schouten (:bas.schouten)]

Comment on attachment 569701 [details] [diff] [review]
Deal with Direct2D device going missing in Azure.

[Approval Request Comment]
Regression caused by (bug #651858):
- Since turning on D2D Azure.
User impact if declined:
- Crash.
Testing completed (on m-c, etc.):
- Standard nightly & Aurora coverage, no reported issues.
Risk to taking this patch (and alternatives if risky):
- Drawing artifacts as opposed to crash.
- Not 100% sure it resolves the crash, as the crash was resolved by riskier patches. Highly likely though.
String changes made by this patch:
- None

Comment 30

[Lukas Blakk [:lsblakk] use ?needinfo]

[Triage Comment]
fixes #5 topcrasher, has baked enough - taking for beta

Comment 31

[Justin Wood (:Callek)]

Trying to help cleanup the landing-queue for approvals, got rejects:

Justin@ORION /d/sources/mozilla-beta
$ hg qpush
applying bug668344
patching file content/canvas/src/nsCanvasRenderingContext2DAzure.cpp
Hunk #1 FAILED at 3075
1 out of 1 hunks FAILED -- saving rejects to file content/canvas/src/nsCanvasRenderingContext2DAzure
.cpp.rej
patching file gfx/layers/basic/BasicLayers.cpp
Hunk #1 FAILED at 1183
1 out of 1 hunks FAILED -- saving rejects to file gfx/layers/basic/BasicLayers.cpp.rej
patching file gfx/thebes/gfxWindowsPlatform.cpp
Hunk #1 FAILED at 491
1 out of 1 hunks FAILED -- saving rejects to file gfx/thebes/gfxWindowsPlatform.cpp.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh bug668344

Comment 32

[Bas Schouten (:bas.schouten)]

I already pushed this to beta. I suspect that's why it didn't work.

Comment 33

[Justin Wood (:Callek)]

(In reply to Bas Schouten (:bas) from comment #32)
> I already pushed this to beta. I suspect that's why it didn't work.

status-11:fixed (though would be good to have the cset added to this bug for bookkeeping

Comment 34

[Scoobidiver (away)]

(In reply to Justin Wood (:Callek) from comment #33)
> status-11:fixed (though would be good to have the cset added to this bug for
> bookkeeping
http://hg.mozilla.org/releases/mozilla-beta/rev/64c6bafaebf6

Comment 35

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0

Verified with following steps on Windows 7:
1. Install pdf.js in Firefox 11 Beta 6
2. Load http://andreasgal.github.com/pdf.js/web/viewer.html
3. Disable hardware acceleration.
4. Re-load the webpage.

No crash with 11Beta6. Could previously reproduce on Firefox 8.

There are also no reports for 11beta in Socorro for this crash signature. http://bit.ly/y9msWv

Comment 36

[Loic]

For the record, another easy way to crash FF10:

1) Open http://people.mozilla.org/~jdaggett/tests/subpixelexplorer.html
2) Disable HWA

FF10 crashes.

Comment 37

[Josh Matthews [:jdm]]

Loic, are you saying that that crash still occurs in FF>10, or that the crash is not reproducible in more recent versions?

Comment 38

[Loic]

(In reply to Josh Matthews [:jdm] from comment #37)
> Loic, are you saying that that crash still occurs in FF>10, or that the
> crash is not reproducible in more recent versions?

1) Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120313 Firefox/13.0a1
Result: no crash

2) Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a2) Gecko/20120313 Firefox/12.0a2
Result: crash after disabling HWA and clicking on "redraw" button
CR: https://crash-stats.mozilla.com/report/index/bp-4a0257a7-ef05-405f-8968-db02e2120313

Comment 39

[Loic]

I have just updated to FF11:

3) Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
Result: no crash

Comment 40

[Alex Keybl [:akeybl]]

(In reply to Loic from comment #38)
> 2) Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a2) Gecko/20120313
> Firefox/12.0a2
> Result: crash after disabling HWA and clicking on "redraw" button
> CR:
> https://crash-stats.mozilla.com/report/index/bp-4a0257a7-ef05-405f-8968-
> db02e2120313

This has a different signature than this bug - can you file a new bug? Thanks.

Comment 41

[Loic]

(In reply to Alex Keybl [:akeybl] from comment #40) 
> This has a different signature than this bug - can you file a new bug?
> Thanks.

Done. See bug 737279.