This bug was filed from the Socorro interface and is report bp-305b6191-d147-4ad3-9cdd-46d672120921 . ============================================================= Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20100101 Firefox/16.0 Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0 Beta 4 Steps: 1. Go to maps.google.com 2. Enable WebGL 3. Enter street view and navigate for a while Result: After some time (a few minutes) Firefox crashes. Crash was reproduced on win XP and Win 7, and most of the times there was no signature: - https://crash-stats.mozilla.com/report/index/bp-87fbcae4-ca82-4ff8-bc29-f6db02120921 - https://crash-stats.mozilla.com/report/index/bp-6307afdf-c2e3-42ea-ba6b-6995a2120921 - http://crash-stats.mozilla.com/report/index/bp-ad748946-8eff-4be5-ba97-c17ac2120921 - http://crash-stats.mozilla.com/report/index/bp-480c8174-fc11-4cbf-bf15-54e502120921 On Win XP, sometimes OS restarted itself with the above steps instead of crashing Firefox.

I haven't been able to reproduce the crash yet, however I am not sure I am enabling WebGL correctly. When I go to maps.google.com I get a notification on the page asking me to try MapsGL which itself uses WebGL. Is this what you are referring to? When I try it I get another notification saying my hardware isn't supported and I get the option to go back to classic maps. I also tried force-enabling WebGL from the preferences in about:config, which then allows me to try the MapsGL version, but so far, after a few minutes of navigating around in street view mode I have not crashed.

(In reply to juan becerra [:juanb] from comment #1) > I haven't been able to reproduce the crash yet, however I am not sure I am > enabling WebGL correctly. When I go to maps.google.com I get a notification > on the page asking me to try MapsGL which itself uses WebGL. Is this what > you are referring to? Yes, that's how you enable WebGL for google maps. We didn't have any problems with enabling it (whithout changing anything in about:config) and we reproduced the crash on 3 different machines (2 Win XP, 1 Win 7).

That error message is actually from ThebesLayerD3D9. http://mxr.mozilla.org/mozilla-central/search?string=Failed%20to%20create%20temporary%20texture%20in%20system%20memory 2147942414 is 0x8007000E, which is E_OUTOFMEMORY. Is there any massive growth apparent in about:memory prior to the crash? CC'ing Bas, since this is in D3D9 layers.

(In reply to Jeff Gilbert [:jgilbert] from comment #3) > > 2147942414 is 0x8007000E, which is E_OUTOFMEMORY. Is there any massive > growth apparent in about:memory prior to the crash? > Yes, the memory continuously grows from ~250MB (when I started navigating) to ~1GB after about 2 minutes and the Firefox crashed. Unlike classic street view, memory is never released during navigation (without WebGL, memory grows from 130MB to ~180MB and then is released back to 130 and so on). After the crash, in about:memory page there is the following warning: WARNING: the following values are negative or unreasonably large. explicit/(7 tiny) explicit/(7 tiny)/heap-unclassified This indicates a defect in one or more memory reporters. The invalid values are highlighted. and some values are highlighted in red (see attached screenshot).

Steps from bug description crash Linux (Ubuntu 12.04 32bit) as well.

(In reply to Mihaela Velimiroviciu [QA] from comment #5) > Steps from bug description crash Linux (Ubuntu 12.04 32bit) as well. Crash report: https://crash-stats.mozilla.com/report/index/74ea51da-722f-4b78-9996-147da2120924

(In reply to Mihaela Velimiroviciu [QA] from comment #6) > Crash report: > https://crash-stats.mozilla.com/report/index/74ea51da-722f-4b78-9996- > 147da2120924 It's bug 733324.

Why haven't we pulled together a regression window over the past two weeks? This should have been nominated for tracking much sooner...

Jeff/Bas - whose bug is this? Please prepare a patch for all branches (including mozilla-release). We won't sping a 16.0.1 for this specifically, but may take it in a dot release.

Mihaela, please provide a regression range for this bug ASAP.

Last good nightly: 2011-07-05 (last 7.0a1 build) First bad nightly: 2011-07-06 (first 8.0a1 build) Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3f27dc203e62&tochange=58101c64c83c

Do you have a Nightly crash report with debug symbols (no XUL.dll in the stack trace)?

The crashes I got on Nightly don't have crashing thread (https://crash-stats.mozilla.com/report/index/bp-ca9ede30-2476-4d67-83cd-60a6d2121010)

(In reply to Mihaela Velimiroviciu [QA] from comment #11) > Last good nightly: 2011-07-05 (last 7.0a1 build) > First bad nightly: 2011-07-06 (first 8.0a1 build) > > Pushlog: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=3f27dc203e62&tochange=58101c64c83c Given this, no need to track for FF16. Is anybody else able to reproduce this bug?

(In reply to Alex Keybl [:akeybl] from comment #14) > Given this, no need to track for FF16. Comment 13 shows an empty signature which is #1 top crasher. In addition, I see many comments about Google Maps with that empty signature: https://crash-stats.mozilla.com/report/list?signature=EMPTY%3A+no+crashing+thread+identified%3B+corrupt+dump This bug highlights a maybe widespread crash previously hidden from developers although it's not new for users.

(In reply to Scoobidiver from comment #15) > (In reply to Alex Keybl [:akeybl] from comment #14) > > Given this, no need to track for FF16. > Comment 13 shows an empty signature which is #1 top crasher. In addition, I > see many comments about Google Maps with that empty signature: > https://crash-stats.mozilla.com/report/ > list?signature=EMPTY%3A+no+crashing+thread+identified%3B+corrupt+dump > > This bug highlights a maybe widespread crash previously hidden from > developers although it's not new for users. OK - bjacob, can you take a stab at this for FF17 over the next 2 weeks? Please let QA know if you have a hard time reproducing.

(note that we would not block the release on this, given how long the bug has been present)

I will take a look. If it is a Layers/compositing bug, I'm not the best person, but I can at least bisect down to 1 changeset and find the right person.

Oh, it is a regression from july _2011_. I can't bisect easily anymore, as it requires atlbase.h (like pre-9.0 versions did). I'll give a stab at debugging current m-c.

So, I apparently don't get to reproduce this, because I crash earlier --- I crash immediately (within seconds) of clicking the button to enable MapsGL. The crash I get is ANGLE issue 350: https://code.google.com/p/angleproject/issues/detail?id=350 Which is fixed in ANGLE r1278. So I will update our ANGLE copy to it ASAP, that's the only thing I can do on my end for now, but I have absolutely no reason to think that that will fix the issue originally discussed here.

This patch imports ANGLE r1278 (just this revision, not a full upgrade) which fixes ANGLE bug 350. It's a very small patch so it's possible to take it on beta. This may or may not be the issue at hand here. I can't reproduce the issue being reported here. I can only reproduce ANGLE bug 350. That's all I think I can do here.

http://hg.mozilla.org/integration/mozilla-inbound/rev/94ea624a1d8e Please retry once this hits the Nightlies.

This is in Nightly now. Can you still reproduce the bug?

QA please verify that this doesn't reproduce in Nightly so we can get an uplift nomination here if not.

Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/19.0 Firefox/19.0 Build id: 20121101030705 I used the latest Nightly build to verify this and it is still crashing (even quicker), but with other signature: [@ js::ObjectImpl::hasClass(js::Class const*)]. Reports: http://crash-stats.mozilla.com/report/index/bp-29bc065a-4c89-440a-a3d1-226142121101 http://crash-stats.mozilla.com/report/index/bp-c6d22a85-4123-4445-963d-c43e52121101 There is already a bug logged for this crash signature: bug #791999. We cannot verify the fix for this bug until bug #791999 is fixed.

I would think as long as you don't get the same signature or stack for this bug report that this can be marked verified fixed. As you point out, bug 791999 will take care of the other signature. Scoobidiver, Lukas, what do you think?

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #27) > Scoobidiver, Lukas, what do you think? I disagree. bug 791999 hides this bug so nothing has been verified.

Okay, thanks Scoobidiver. Based on that, I'm marking this blocked until bug 791999 is fixed. We won't be able to verify this until such time.

At this stage it's not likely we'll have a fix in time for 17, marking wontfix and we'll continue tracking this and bug 791999 for 18.

Meh, it's a bit annoying that this bug is staying in my list of assigned-tracked-bugs even though it's probably fixed by the patch that we already landed, because of bug 791999.

Is this reproducible on 18? If so, the patch looks pretty small, is this something we want to uplift?

Comment on attachment 674706 [details] [diff] [review] Import ANGLE r1278 [Approval Request Comment] Bug caused by (feature/regressing bug #): Previous ANGLE update. User impact if declined: This crash, among others. Testing completed (on m-c, etc.): On Aurora 19. Risk to taking this patch (and alternatives if risky): No risk. String or UUID changes made by this patch: None.

Comment on attachment 674706 [details] [diff] [review] Import ANGLE r1278 [Triage Comment] Low risk fix for a recent WebGL crash regression. Approving for Beta 18.

(In reply to Alex Keybl [:akeybl] from comment #34) > Comment on attachment 674706 [details] [diff] [review] > Import ANGLE r1278 > > [Triage Comment] > Low risk fix for a recent WebGL crash regression. Approving for Beta 18. FWIW it's not a recent regression. see comment 11. But I still agree with the conclusion :-)

Still crashing with empty signature with Firefox 21 RC, Win 8 32bit (in Google street view, WebGL enabled): https://crash-stats.mozilla.com/report/index/bp-275abaf7-0cbd-46e6-a9e1-941f22130508

On May 7, there are 971 crashes with this error message out of 190623 crashes in 20.0.1 ie 0.51% of all crashes and #19 top crasher, 165 crashes out of 45611 crashes in 21.0 Beta ie 0.36% of all crashes and #24 top crasher in 21.0b6, and 8 crashes out of 2414 crashes in 22.0a2 ie 0.33% of all crashes and #18 top crasher.

Benoit - any ideas for resolution in the FF22 on beta (24 on m-c) timeframe?

Given that this is a 2 year old open bug, I don't see the rationale for backporting a fix to the channels. Let me also un-assign myself from this bug: I haven't worked on WebGL much lately and should no longer be considered the default assignee for WebGL bugs (Jeff Gilbert would be that person).

Regarding the "2 years old" statement, see comment 11.

It's #14 top crasher in 21.0 (177 crashes over the last day).

I don't see any more the "Enable mapsGL" button. What does this mean ?

(In reply to Paul Silaghi [QA] from comment #43) > I don't see any more the "Enable mapsGL" button. What does this mean ? WebGL is no longer experimental and will be includde in the new Google Maps currently in Preview: https://www.youtube.com/watch?v=inKGPE2XqbM

Based on https://crash-analysis.mozilla.com/crash_analysis/20130719/20130719-pub-crashdata.csv.gz, there are 1395 crashes over the last day in 22.0 with this error making it #6 top browser crasher.

The error message is a graphics one (Direct3D 9).

Indeed, and some hg annotate shows that this code (in ThebesLayerD3D9.cpp) was added by Bug 593604, Part 9. That makes Roc and Bas the right people to ask about this error message.

Better still, Nick!

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #48) > Better still, Nick! I had a play with this. I couldn't reproduce the crash, but looking at those CreateTexture calls, I would guess this is due either to OOM or trying to get a texture larger than the driver supports. But we require a minimum maximum texture size of 4096, so people are going to have to have a really large screen to hit that limit. And we use D3DPOOL_SYSTEMMEM, so I'm not even sure if there is a max size. OK, so I observed memory use. I couldn't actually get it to OOM, but I was just using one tab, and with a debug build it was painfully slow. Maps is a total memory hog. I got up to 2gb in no time, I'm sure that in normal browsing conditions you could OOM easily. So my money is on OOM. I guess the next step is figuring out where all that memory is going and why it doesn't get released (I'm not volunteering for this, btw - my TODO queue is getting ridiculous).

I think it's the Direct3D9 version of bug 867226 for OpenGL. Is it possible to implement the same mechanism?

(In reply to Scoobidiver from comment #50) > I think it's the Direct3D9 version of bug 867226 for OpenGL. > Is it possible to implement the same mechanism? They are similar, but I think they might be different. As far as I can tell here we don't have oversize textures. We should find out for sure why we are using up so much memory here before we try fixes.

(In reply to Nick Cameron [:nrc] from comment #49) > (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #48) > > Better still, Nick! > > I had a play with this. I couldn't reproduce the crash, but looking at those > CreateTexture calls, I would guess this is due either to OOM or trying to > get a texture larger than the driver supports. But we require a minimum > maximum texture size of 4096, so people are going to have to have a really > large screen to hit that limit. And we use D3DPOOL_SYSTEMMEM, so I'm not > even sure if there is a max size. > > OK, so I observed memory use. I couldn't actually get it to OOM, but I was > just using one tab, and with a debug build it was painfully slow. Maps is a > total memory hog. I got up to 2gb in no time, I'm sure that in normal > browsing conditions you could OOM easily. So my money is on OOM. I guess the > next step is figuring out where all that memory is going and why it doesn't > get released (I'm not volunteering for this, btw - my TODO queue is getting > ridiculous). This remains a topcrash, is there anything we can do to fail instead of crashing here roc? nrc sounds slammed.

Alright, Jeff maybe.

Due to compatibility issues I am stuck with using FF21 on WinXP, and experience this crash around 6 times a day (usually after loading youtube two or three times). I was just wondering if any of the root causes were identified and if there is anything I can do while waiting for an upgrade path.

(In reply to report0 from comment #54) > Due to compatibility issues I am stuck with using FF21 on WinXP I don't know what your compatibility issues are but if you are unable to update your Firefox build you should file a bug about that so it can be investigated. As a work around you could download a new copy of Firefox from firefox.com if the updater continues to fail. Firefox 21 is over a year old and we've patched numerous security flaws since then. You're really leaving yourself open to being exploited by continuing to use that Firefox version. If you want help getting your Firefox up to date then please submit a request at support.mozilla.org. If running the latest Firefox is not an option, I'd much rather you switch to an up to date version of Internet Explorer, Chrome, or Safari.

Jeff, this is still assigned to you. Is there anything left to be done here?

This crash is still reported with 5 reports in Firefox 47. However, only 1 had an empty signature, the others are split evenly between [@ mozilla::layers::CompositingRenderTargetD3D9::CompositingRenderTargetD3D9] and [@ xul.dll@0xcd45ed | xul.dll@0xc9b355 | xul.dll@0xcc687b | xul.dll@0x80ff9f].

Closing because no crash reported since 12 weeks.

Closing because no crash reported since 12 weeks.