803949 - Crash [@ gfxContext::PushClipsToDT]

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Jesse Ruderman]

Attachment: testcase (crashes Firefox when loaded)

Only on Windows?

Comment 1

[Jesse Ruderman]

Attachment: stack

Comment 2

[Jesse Ruderman]

There's a topcrash with the same signature: bug 758531.

I'm on Windows 7 (64-bit), fwiw.

Comment 3

[Scoobidiver (away)]

It doesn't crash for me.
What is your graphics configuration (see about:support)?

Comment 4

[Bas Schouten (:bas.schouten)]

I don't reproduce either on my main dev machine. I wonder if this is NVidia only.

Comment 5

[Jesse Ruderman]

Attachment: about:support - graphics

Comment 6

[Jesse Ruderman]

Bas helped me debug this a bit.

In gfxContext::GetAzureDeviceSpaceClipBounds, when i==3 and c==0, the "else" path is taken.  clip.transform is

[0  0  NaN
 0  1  NaN]

These NaNs poison the rest of the calculation, so the clipBounds seen by gfxContext::PushNewDT is all NaNs.

Comment 7

[Jesse Ruderman]

Attachment: patch for debugging

Comment 8

[Bas Schouten (:bas.schouten)]

(In reply to Jesse Ruderman from comment #7)
> Created attachment 673729 [details] [diff] [review]
> patch for debugging

So I still can't reproduce this, but the following information could really help:

1. Find out when gfxContext::ChangeTransform changes the transform to the invalid state
2. I suspect 1 will lead us to conclude NudgeToIntegers, in which case it would be great where it's going all wrong in that function!

Comment 9

[Nick Cameron [:nrc]]

I tried to reproduce this too (on Nvidia HW) and couldn't. Should it just crash on opening the test case and/or when starting FF on that page? Are there any other necessary STR?

Comment 10

[Jesse Ruderman]

Attachment: NaNnotated stack

Comment 11

[Bas Schouten (:bas.schouten)]

(In reply to Jesse Ruderman from comment #10)
> Created attachment 673771 [details]
> NaNnotated stack

Sorry to bug you again Jesse! Could you look in layout/base/nsLayoutUtils.cpp inside ComputeSnappedImageDrawingParameters to see where these #IND is coming from?

Comment 12

[Jesse Ruderman]

The bad division comes from the call at 
http://hg.mozilla.org/mozilla-central/annotate/1c3e4cb1f754/layout/base/nsLayoutUtils.cpp#l3739 
with imageSize = {width: 0., height: 768.}.

Comment 13

[Jesse Ruderman]

Attachment: patch for debugging, v2

Comment 14

[Bas Schouten (:bas.schouten)]

Attachment: Do not draw when imageSize is 0

This could be causing the crashes we're seeing since , in the past setting this would be innocent, i.e. it would cause us not to draw anything, like we should, but it wouldn't cause a crash. Now that we're making temp surfaces we'll try and create NaN size surfaces, which actually causes us to crash. The right fix seems to be to avoid this division-by-zero altogether.

I have no idea why my system does -not- get this function called with a 0 image size on this testcase.

Comment 15

[Bas Schouten (:bas.schouten)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/c78126b31487

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c78126b31487

Should this have a test?

Comment 17

[Bas Schouten (:bas.schouten)]

(In reply to Ryan VanderMeulen from comment #16)
> https://hg.mozilla.org/mozilla-central/rev/c78126b31487
> 
> Should this have a test?

Neither me nor Nick can reproduce this crash. We could add Jesse's test to crashtests, but we wouldn't know if the test machines are actually crashing on this and I suppose that would make the value of a test questionable.

Comment 18

[Jesse Ruderman]

Even if the test doesn't "work" on our current set of test machines, it can still be valuable by catching regressions on developers' machines, or as a starting point for the DOM fuzzer to make further mutations.

I'm still baffled by why the test doesn't even show the divide-by-zero issue for Bas. (Bas, did you try saving the testcase and loading it from a file: URL?  Could it depend on the window size?)

Comment 19

[Bas Schouten (:bas.schouten)]

(In reply to Jesse Ruderman from comment #18)
> Even if the test doesn't "work" on our current set of test machines, it can
> still be valuable by catching regressions on developers' machines, or as a
> starting point for the DOM fuzzer to make further mutations.
> 
> I'm still baffled by why the test doesn't even show the divide-by-zero issue
> for Bas. (Bas, did you try saving the testcase and loading it from a file:
> URL?  Could it depend on the window size?)

I tried a wide variety of window sizes thinking that might be the culprit, but not loading from disk.

Comment 20

[Jesse Ruderman]

I filed bug 804924 to see if it makes sense to add some not-NaN assertions.

Comment 21

[Scoobidiver (away)]

I think it should be uplifted to Aurora along with bug 758531. Indeed, they landed in the same build and we don't know which one was the most top crasher contributor.

Comment 22

[Bas Schouten (:bas.schouten)]

Comment on attachment 674030 [details] [diff] [review]
Do not draw when imageSize is 0

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 778367
User impact if declined: Top 10 crasher
Testing completed (on m-c, etc.): m-c
Risk to taking this patch (and alternatives if risky): Very low, this fixes a bug which would cause other problems too before bug 778367. Bug 778367 just turned this into a crasher.
String or UUID changes made by this patch: None

Comment 23

[Bas Schouten (:bas.schouten)]

http://hg.mozilla.org/releases/mozilla-beta/rev/ae3b21c9a569

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e82ab79e04a4

Comment 25

[Simona Badau, Desktop QA]

Verified that Firefox 17 beta 5 does not crash when loading the test case attached in the Description (I could reproduce the crash on the Nightly from 2012-10-21), but neither does Firefox 17 beta 3 (and it should). 

I verified the Socorro reports and I found a couple of crashes that happened after the fixes for this bug landed on Firefox 17 beta 4, on the latest Nightly and Aurora. The majority of them are on Windows 8 - Bug 805406 takes care of that - but there are some crash reports also on Windows 7.

The crash reports are: 
* Firefox 17 beta 4:
https://crash-stats.mozilla.com/report/index/406eb276-869c-48be-9286-e004f2121107
https://crash-stats.mozilla.com/report/index/1e8dba72-beb5-40dd-a0a9-ec2592121106
https://crash-stats.mozilla.com/report/index/aeda7489-f8ee-441f-8390-73f212121106
https://crash-stats.mozilla.com/report/index/219f2db8-0b41-4d56-bf56-ab7782121106
https://crash-stats.mozilla.com/report/index/9a639bd1-1b94-42b8-b4c1-513d22121106
https://crash-stats.mozilla.com/report/index/8e3580c7-604b-414b-91ea-383ca2121105
https://crash-stats.mozilla.com/report/index/071e19e6-9a53-43ff-a263-2adfd2121105
https://crash-stats.mozilla.com/report/index/67d51a21-869a-4040-9707-53db32121104
https://crash-stats.mozilla.com/report/index/0d547657-c793-41ae-abb2-319fe2121103
https://crash-stats.mozilla.com/report/index/d854e473-3802-490c-9107-488ce2121103
* Aurora
https://crash-stats.mozilla.com/report/index/06a1d6a6-3937-4348-baae-6a9c32121106
* Nightly
https://crash-stats.mozilla.com/report/index/109a856b-541f-43e2-bbca-b0d4b2121104
https://crash-stats.mozilla.com/report/index/e91eed83-fa42-4439-b60f-bc81e2121104

Are these crashes related with this bug? Is this expected in any way or should I file a separate bug?

Comment 26

[Scoobidiver (away)]

(In reply to Simona B [QA] from comment #25)
> but neither does Firefox 17 beta 3 (and it should). 
There's no evidence that this bug was an old regression. The patch landed in Beta and Aurora for safety. Bug 758531 tracks remaining crashes in 17.0 Beta.

> The majority of them are on Windows 8 - Bug 805406 takes care of that - but there
> are some crash reports also on Windows 7.
Bug 805406 takes also care of remaining crashes on Windows 7 in the trunk.

Comment 27

[u279076]

Scoobidiver, can this bug be marked verified? If there is follow-up work on other bugs I'm not sure what more QA can do for *this* bug apart from what's already been done in comment 25.

Comment 28

[Scoobidiver (away)]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #27)
> Scoobidiver, can this bug be marked verified?
Yes for the trunk, but no for Beta. This bug is based on a testcase, not on crash stats.

Comment 29

[u279076]

(In reply to Scoobidiver from comment #28)
> Yes for the trunk, but no for Beta. This bug is based on a testcase, not on
> crash stats.

Simona said the testcase does not crash Firefox 17.0b5 in comment 25. Can this not be marked verified for Beta based on that?

Comment 30

[Scoobidiver (away)]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #29)
> Simona said the testcase does not crash Firefox 17.0b5 in comment 25. Can
> this not be marked verified for Beta based on that?
It depends on the meaning of verified:
No, if you verify that a problem no longer exist.
Yes, if you verify that a problem doesn't exist.

Comment 31

[u279076]

Well I don't see that there's anything else QA can do to test this is fixed.