The default bug view has changed. See this FAQ.

Crash [@ gfxContext::PushClipsToDT]

RESOLVED FIXED in Firefox 17

Status

()

Core
Graphics
--
critical
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: Jesse Ruderman, Assigned: bas)

Tracking

(Blocks: 1 bug, {crash, testcase})

Trunk
mozilla19
x86_64
Windows 7
crash, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(firefox17 fixed, firefox18 fixed, firefox19 fixed)

Details

(Whiteboard: [qa-], crash signature)

Attachments

(6 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 673671 [details]
testcase (crashes Firefox when loaded)

Only on Windows?
(Reporter)

Comment 1

5 years ago
Created attachment 673672 [details]
stack
(Reporter)

Comment 2

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

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

Comment 3

5 years ago
It doesn't crash for me.
What is your graphics configuration (see about:support)?
Crash Signature: [@ gfxContext::PushClipsToDT] → [@ gfxContext::PushClipsToDT(mozilla::gfx::DrawTarget*)]
Depends on: 758531
Flags: needinfo?(jruderman)
(Assignee)

Comment 4

5 years ago
I don't reproduce either on my main dev machine. I wonder if this is NVidia only.
(Reporter)

Comment 5

5 years ago
Created attachment 673718 [details]
about:support - graphics
Flags: needinfo?(jruderman)
(Reporter)

Comment 6

5 years ago
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.
(Reporter)

Comment 7

5 years ago
Created attachment 673729 [details] [diff] [review]
patch for debugging
(Assignee)

Comment 8

5 years ago
(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!
Flags: needinfo?(jruderman)

Comment 9

5 years ago
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?
(Reporter)

Comment 10

5 years ago
Created attachment 673771 [details]
NaNnotated stack
Flags: needinfo?(jruderman)
(Assignee)

Comment 11

5 years ago
(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?
(Reporter)

Comment 12

5 years ago
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.}.
(Reporter)

Comment 13

5 years ago
Created attachment 673945 [details] [diff] [review]
patch for debugging, v2
Attachment #673729 - Attachment is obsolete: true
(Assignee)

Comment 14

5 years ago
Created attachment 674030 [details] [diff] [review]
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.
Assignee: nobody → bas
Status: NEW → ASSIGNED
Attachment #674030 - Flags: review?(roc)
Attachment #674030 - Flags: review?(roc) → review+
(Assignee)

Comment 15

5 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/c78126b31487
https://hg.mozilla.org/mozilla-central/rev/c78126b31487

Should this have a test?
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
(Assignee)

Comment 17

5 years ago
(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.
(Reporter)

Comment 18

5 years ago
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?)
(Assignee)

Comment 19

5 years ago
(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.
(Reporter)

Comment 20

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

Comment 21

5 years ago
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.
(Assignee)

Comment 22

5 years ago
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
Attachment #674030 - Flags: approval-mozilla-beta?
Attachment #674030 - Flags: approval-mozilla-aurora?
Attachment #674030 - Flags: approval-mozilla-beta?
Attachment #674030 - Flags: approval-mozilla-beta+
Attachment #674030 - Flags: approval-mozilla-aurora?
Attachment #674030 - Flags: approval-mozilla-aurora+
(Assignee)

Comment 23

5 years ago
http://hg.mozilla.org/releases/mozilla-beta/rev/ae3b21c9a569
status-firefox17: --- → fixed
status-firefox18: --- → affected
status-firefox19: --- → fixed
https://hg.mozilla.org/releases/mozilla-aurora/rev/e82ab79e04a4
status-firefox18: affected → fixed
Flags: in-testsuite? → in-testsuite-
Keywords: verifyme
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

4 years ago
(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.
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

4 years ago
(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.
(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

4 years ago
(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.
Well I don't see that there's anything else QA can do to test this is fixed.
Keywords: verifyme
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.