Only on Windows?

There's a topcrash with the same signature: bug 758531. I'm on Windows 7 (64-bit), fwiw.

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

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

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.

(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!

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?

(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?

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

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.

https://hg.mozilla.org/mozilla-central/rev/c78126b31487 Should this have a test?

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

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

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

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

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

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?

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

(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?

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