Build Identifier: http://hg.mozilla.org/mozilla-central/rev/0a7410527788 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/13.0 Firefox/13.0a1 ID:20120220074932 report bp-9accff3d-efe7-4730-a580-0b90e2120221 . Crash during test for Bug 729026 Reproducible: cannot Steps to Reproduce: 1. Start Firefox with new profile 2. Visit http://maps.google.com/ and activate the experimental MapsGl. 3. Move zooming slider upward slowly. Actual Results: Browser crashes Expected Results: No crash

This is not a duplicate of Bug 715401, because Firefox/13.0a1 ID:20120220074932 includes the patch of Bug 715401.

I found a reproducible STR, Reproducible: Frequently Steps to Reproduce: 1. Start Firefox with new profile 2. Visit http://maps.google.com/ and activate the experimental MapsGl. 3. Resize window size so that zooming slider overlaps with satellite icon. (See screen shot) 4. Move zooming slider upward to top-end and release mouse at + icon. 5. If browser does not crash, Reload page and go to Step 4. Actual Results: Browser crashes Expected Results: No crash

I think bug 715401 should be reopened as the stack is identical.

See https://bugzilla.mozilla.org/show_bug.cgi?id=715401#c50. Asking Joe in roc's absence.

Try run for 401df4f4454d is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=401df4f4454d Results (out of 49 total builds): success: 42 warnings: 3 failure: 4 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bschouten@mozilla.com-401df4f4454d

Comment on attachment 600902 [details] [diff] [review] Try hard to have a valid mTarget Review of attachment 600902 [details] [diff] [review]: ----------------------------------------------------------------- This is only OK if you also remove all null checks. (It's ok if the null check removal only happens on m-c.) I wonder if it would be better if we had some form of "Empty" DrawTarget instead of a 1x1 "default system" (in this case, D2D) DrawTarget. This would make explicit that we won't draw anything to such a DrawTarget, and drawing from it will also be impossible. Right now we could conceivably draw a 1-pixel canvas in the place of a too-large canvas. How about gfxPlatform::GetDummyDrawTarget()?

(In reply to Joe Drew (:JOEDREW!) from comment #7) > Comment on attachment 600902 [details] [diff] [review] > Try hard to have a valid mTarget > > Review of attachment 600902 [details] [diff] [review]: > ----------------------------------------------------------------- > > This is only OK if you also remove all null checks. (It's ok if the null > check removal only happens on m-c.) mTarget can still end up being NULL if D2D was switched off, this is why the patch in bug 715401 was needed in the first place. This just makes it a lot less likely to become NULL. > > I wonder if it would be better if we had some form of "Empty" DrawTarget > instead of a 1x1 "default system" (in this case, D2D) DrawTarget. This would > make explicit that we won't draw anything to such a DrawTarget, and drawing > from it will also be impossible. Right now we could conceivably draw a > 1-pixel canvas in the place of a too-large canvas. I agree, but we'd need Skia everywhere for that to have a DrawTarget available everywhere. Unless you mean we create an actual 'stub' DrawTarget type. Are people who can actually reproduce this bug seeing it fixed with my try build?

This tests for this crash.

Comment on attachment 600902 [details] [diff] [review] Try hard to have a valid mTarget [Approval Request Comment] Regression caused by (bug #715401): User impact if declined: - Easily crashing canvas. Testing completed (on m-c, etc.): - None. Risk to taking this patch (and alternatives if risky): - Almost none. This mostly returns us to old behavior but keeps 715401 fixed. String changes made by this patch: - None

(In reply to Bas Schouten (:bas) from comment #10) > Risk to taking this patch (and alternatives if risky): > - Almost none. This mostly returns us to old behavior but keeps 715401 fixed. Do we feel that the crash signature nsCanvasRenderingContext2DAzure::ClearRect(float, float, float, float) will disappear completely after taking this fix? The previous speculative patch in 715401 didn't obviously fix the issue, and the crash #s would have been conflated with bug 729116. Let's land on m-c today in preparation for possible uplift tomorrow based upon nightly testing.

(In reply to Alex Keybl [:akeybl] from comment #11) > (In reply to Bas Schouten (:bas) from comment #10) > > Risk to taking this patch (and alternatives if risky): > > - Almost none. This mostly returns us to old behavior but keeps 715401 fixed. > > Do we feel that the crash signature > nsCanvasRenderingContext2DAzure::ClearRect(float, float, float, float) will > disappear completely after taking this fix? The previous speculative patch > in 715401 didn't obviously fix the issue, and the crash #s would have been > conflated with bug 729116. > > Let's land on m-c today in preparation for possible uplift tomorrow based > upon nightly testing. The two crashes have different causes, the patch in 715401 fixed one cause, but triggered the other. This patch will make both -these- crashes disappear. There's still an unfortunate combination of circumstances that could trigger this crash signature, but it should be even rarer than 729116.

https://hg.mozilla.org/integration/mozilla-inbound/rev/21584311ba0e https://hg.mozilla.org/integration/mozilla-inbound/rev/31a715f47164 Follow-up to disable test on OS X with accelerated layers: https://hg.mozilla.org/integration/mozilla-inbound/rev/aa58a8f53aca

https://hg.mozilla.org/mozilla-central/rev/21584311ba0e https://hg.mozilla.org/mozilla-central/rev/31a715f47164 https://hg.mozilla.org/mozilla-central/rev/aa58a8f53aca

Comment on attachment 600902 [details] [diff] [review] Try hard to have a valid mTarget [Triage Comment] Approved for Aurora 12 and Beta 11. Please land asap so that this makes it for our fifth beta of Firefox 11 (going to build tonight).

https://hg.mozilla.org/releases/mozilla-aurora/rev/ff481fda4945 https://hg.mozilla.org/releases/mozilla-beta/rev/57cd04c55898

I have a case where i can trigger this crash with direct2d enabled and upon finding this bug i tried with Firefox Aurora 12.0a2 (2012-03-01). the crash is indeed fixed but the canvas is initialized correctly: i describe whats happening that triggers this and results in a broken canvas: * init canvas (300x300) * call getContext("2d") * (draw on canvas) * resize canvas: make it bigger until the setAttribute call throws NS_ERR_OUTOFMEMORY(or similar) * resize the canvas back to something smaller * try to draw onto the canvas the result is a canvas 2d context that is not usable (maybe i could draw a 1x1 image from the patches that i looked at but that doesn't count) however if i disable direct2d i get: * canvas with huge resolution possible * does not crash * doesn't have weird direct2d bugs(i had to deal with a few already - however i have had no time to file them back then) * no noticeable performance degradation (for my purposes) so if the creation of a drawing context with direct2d fails maybe try the old way because that worked a lot better... a 1x1 canvas really isn't useful - especially since without direct2d it would work much better

(In reply to cobexer from comment #17) > I have a case where i can trigger this crash with direct2d enabled and upon > finding this bug i tried with Firefox Aurora 12.0a2 (2012-03-01). > the crash is indeed fixed but the canvas is initialized correctly: > > i describe whats happening that triggers this and results in a broken canvas: > * init canvas (300x300) > * call getContext("2d") > * (draw on canvas) > * resize canvas: make it bigger until the setAttribute call throws > NS_ERR_OUTOFMEMORY(or similar) > * resize the canvas back to something smaller > * try to draw onto the canvas > the result is a canvas 2d context that is not usable (maybe i could draw a > 1x1 image from the patches that i looked at but that doesn't count) > > however if i disable direct2d i get: > * canvas with huge resolution possible > * does not crash > * doesn't have weird direct2d bugs(i had to deal with a few already - > however i have had no time to file them back then) > * no noticeable performance degradation (for my purposes) > > so if the creation of a drawing context with direct2d fails maybe try the > old way because that worked a lot better... > a 1x1 canvas really isn't useful - especially since without direct2d it > would work much better We can't really switch at this point, soon we will be able to when Skia is working. You can safely recreate the context though.

There are still crashes with the same volume in 13.0a1 and 12.0a2 after the patch landed. Alice, are you able to reproduce it with your STR?

I cannot test this due to Bug 732706 now.

(In reply to Scoobidiver from comment #19) > There are still crashes with the same volume in 13.0a1 and 12.0a2 after the > patch landed. > > Alice, are you able to reproduce it with your STR? I cannot reproduce anymore in latest m-c hourly. http://hg.mozilla.org/mozilla-central/rev/ed57abebd328 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120303 Firefox/13.0a1 ID:20120303051507

Verified on: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 BuildID: 20120305181207 The issue doesn't reproduce anymore with Alice's steps. When verifying the crash stats on Socorro http://bit.ly/A8zdM7, there are reports that the crash reproduces on 20120305181207 builds. Considering that I couldn't reproduce the crash and that this crash is also associated with bug 715401 (which is still open), I will mark the bug as verified on Firefox 11.

Verified as fixed on Firefox 12.0 beta 2: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 BuildID: 20120320212821 The issue doesn't reproduce anymore with Alice's steps. On Socorro, there are some reports of this crash on Fx 12 beta 1 but, considering that I couldn't reproduce the crash and that this crash is also associated with bug 715401 (which is still open), I will mark the bug as verified on Firefox 12.

A correction to my previous comment, the user agent was actually: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20100101 Firefox/12.0