It's a new crash signature that first appeared in 11.0a2/20111222 and 12.0a1/20111223. It's #7 top crasher in 11.0a2 on Mac OS X. Here are some comments: "zooming out of a map of my facebook checkins (in an app-tab)" "zooming/panning around a map embedded on the Petco storefinder page. i had a dozen or so additional tabs open at the time." Signature mozalloc_abort | NS_DebugBreak_P | mozilla::gl::GLContext::SetBlitFramebufferForDestTexture More Reports Search UUID e2dc7588-54e5-4ab5-89cf-38de62120111 Date Processed 2012-01-11 19:51:50 Uptime 22648 Last Crash 7.1 weeks before submission Install Age 10.4 hours since version was first installed. Install Time 2012-01-11 17:30:08 Product Firefox Version 12.0a1 Build ID 20120111031049 Release Channel nightly OS Mac OS X OS Version 10.7.3 11D42 Build Architecture amd64 Build Architecture Info family 6 model 23 stepping 10 Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0x0 App Notes AdapterVendorID: 0x10de, AdapterDeviceID: 0x 863GL Context? GL Context+ GL Layers? GL Layers+ xpcom_runtime_abort(###!!! ABORT: Framebuffer not complete -- error 0x8cdd: file /builds/slave/m-cen-osx64-ntly/build/gfx/gl/GLContext.cpp, line 2537) EMCheckCompatibility True Frame Module Signature Source 0 libmozalloc.dylib mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:66 1 XUL NS_DebugBreak_P xpcom/base/nsDebugImpl.cpp:388 2 XUL mozilla::gl::GLContext::SetBlitFramebufferForDestTexture gfx/gl/GLContext.cpp:2537 3 XUL mozilla::gl::GLContext::BlitTextureImage gfx/gl/GLContext.cpp:1793 4 XUL mozilla::layers::BasicBufferOGL::BeginPaint gfx/layers/opengl/ThebesLayerOGL.cpp:598 5 XUL mozilla::layers::ThebesLayerOGL::RenderLayer gfx/layers/opengl/ThebesLayerOGL.cpp:778 6 XUL mozilla::layers::ContainerLayerOGL::RenderLayer gfx/layers/opengl/ContainerLayerOGL.cpp:241 7 XUL mozilla::layers::ContainerLayerOGL::RenderLayer gfx/layers/opengl/ContainerLayerOGL.cpp:241 8 XUL mozilla::layers::ContainerLayerOGL::RenderLayer gfx/layers/opengl/ContainerLayerOGL.cpp:241 9 XUL mozilla::layers::LayerManagerOGL::Render gfx/layers/opengl/LayerManagerOGL.cpp:806 10 XUL mozilla::layers::LayerManagerOGL::EndTransaction gfx/layers/opengl/LayerManagerOGL.cpp:430 11 XUL nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:637 12 XUL nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1714 13 XUL PresShell::Paint layout/base/nsPresShell.cpp:5483 14 XUL nsViewManager::Refresh view/src/nsViewManager.cpp:418 15 XUL nsViewManager::DispatchEvent view/src/nsViewManager.cpp:891 16 XUL HandleEvent view/src/nsView.cpp:159 17 XUL nsChildView::DispatchEvent widget/cocoa/nsChildView.mm:1521 18 XUL nsChildView::DispatchWindowEvent widget/cocoa/nsChildView.mm:1531 19 XUL -[ChildView drawRect:inContext:] widget/cocoa/nsChildView.mm:2564 20 XUL -[ChildView drawRect:] widget/cocoa/nsChildView.mm:2470 21 AppKit AppKit@0x54abd 22 AppKit AppKit@0x4f59a 23 AppKit AppKit@0x509b9 More reports at: https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%20|%20NS_DebugBreak_P%20|%20mozilla%3A%3Agl%3A%3AGLContext%3A%3ASetBlitFramebufferForDestTexture

Error 8CDD is GL_FRAMEBUFFER_UNSUPPORTED. We should add some output to see if we really do have a texture whose format is unsupported.

I can consistently reproduce this crash on the Petco storefinder map (http://www.petco.com/content/locator/SearchResult.aspx?city=&state=&zip=22043&origin=home&veterinary=0&fullGrooming=0&selfGrooming=0&education=0&photography=0&aquatics=0&petcostore=0&Nav=2) by zooming in and out and panning around. I can also reproduce it at http://www.bing.com/maps, again by zooming in and out and panning around, though it seems to take longer to crash than the embedded map above. The texture format is GL_RGBA, so there really isn't a good reason to get GL_FRAMEBUFFER_UNSUPPORTED. This is only happening when the texture attached to the framebuffer is large (larger than 10000 by 10000). We really shouldn't have textures this large anyway -- I'll file a follow-up bug for this.

It's #7 top crasher in 11.0b1 on Mac OS X.

It's #2 top crasher in 11.0b3 on Mac OS X.

The crash comments still point to maps (Bing maps and embedded Bing maps), but it would be good to confirm this with crash URL data. If this is the case, it would suggest that Bug 721905 is what's causing these crashes.

Can someone in QA take a stab at reproducing this?

I took a stab at reproducing this today on 10.7.3 using some of the Bing URLs that were in the crash reports. So far most of the individual reports I looked at had Bing Maps URLs. I haven't been able to reproduce it yet. One user comments that it happened while using the "Bird's Eye" view feature on Bing maps. The last time I tried getting the URLs it was not escaping out the extra characters to it kept returning zero results.

Should we be tracking this? It's now the #2 Mac regression for beta. Probably won't get fixed but it would be nice if we got it in 12.

bug 731358 contains other STR

(In reply to Matthias Versen (Matti) from comment #10) > bug 731358 contains other STR Let's try to reproduce and get a regression window today. Marcia, can you help with that? (In reply to Sheila Mooney from comment #9) > Should we be tracking this? It's now the #2 Mac regression for beta. > Probably won't get fixed but it would be nice if we got it in 12. We may still be able to perform a backout prior to today's beta 6 go to build. Otherwise, I agree this will likely have to wait until FF12.

Are we sure this is a regression? It could also be a Bing change that exposed a latent bug.

(In reply to Joe Drew (:JOEDREW!) from comment #12) > Are we sure this is a regression? It could also be a Bing change that > exposed a latent bug. I tried out Firefox 6, and panning/zooming Bing caused Firefox's memory usage to spike to 3.2 GB, and CPU usage stayed at 100% for about 30 seconds (Firefox was non-responsive during this time).

I've been trying to reproduce this problem with the information in comment #2 using Fx11b5 on two machines, one running 10.6.7 and another using 10.7.3. I zoom in and out, pan around, change the view preferences in the maps, and I have not been able to crash yet. The response time can be quite slow.

Here are some correlations from today that may help as well - I am still trying to see if I can reproduce: Mac OS X mozalloc_abort | NS_DebugBreak_P | mozilla::gl::GLContext::SetBlitFramebufferForDestTexture|EXC_BAD_ACCESS / KERN_INVALID_ADDRESS (17 crashes) 12% (2/17) vs. 0% (2/410) {3d2ee42e-a6d9-4888-bd17-2148dc7928d7} 12% (2/17) vs. 0% (2/410) craigslistpeek@tech4computer 12% (2/17) vs. 0% (2/410) {dc6fc456-8c2b-4e2d-a397-4929653e900d} (Craigslist car listing filter, https://addons.mozilla.org/addon/10545) 12% (2/17) vs. 2% (7/410) {195A3098-0BD5-4e90-AE22-BA1C540AFD1E} (Garmin Communicator, https://addons.mozilla.org/addon/10278) 12% (2/17) vs. 2% (9/410) https-everywhere@eff.org 12% (2/17) vs. 3% (11/410) {9AA46F4F-4DC7-4c06-97AF-5035170634FE} (ImTranslator, https://addons.mozilla.org/addon/2257) 6% (1/17) vs. 0% (1/410) sixornot@entropy.me.uk 6% (1/17) vs. 0% (1/410) {2e17e2b2-b8d4-4a67-8d7b-fafa6cc9d1d0} (Unhide Passwords, https://addons.mozilla.org/addon/462) 6% (1/17) vs. 0% (1/410) savedpasswords@adamfranco.com 6% (1/17) vs. 0% (1/410) {dc0fa13e-3db0-73ec-e852-912722c85409} (SubmitToTab, https://addons.mozilla.org/addon/483) 6% (1/17) vs. 0% (1/410) urladvisor@kaspersky.com 6% (1/17) vs. 0% (1/410) jid0-RZ1wv8WwA7CKjr2eJZV648uKiuE@jetpack 6% (1/17) vs. 0% (1/410) {9c51bd27-6ed8-4000-a2bf-36cb95c0c947} (Tamper Data, https://addons.mozilla.org/addon/966) 6% (1/17) vs. 0% (1/410) plugin@gameplaylabs.com 6% (1/17) vs. 0% (2/410) {e968fc70-8f95-4ab9-9e79-304de2a71ee1} (User Agent Switcher, https://addons.mozilla.org/addon/59) 6% (1/17) vs. 1% (3/410) omnibar@ajitk.com (Omnibar, https://addons.mozilla.org/addon/8823) 6% (1/17) vs. 1% (3/410) {E29869EB-701C-49C9-9D5C-9AA9228E8F35}

I was able to crash twice during rapid panning and zooming maneuvers on bingmaps.com, but my crash reports looks more like driver crashes: https://crash-stats.mozilla.com/report/index/41799371-20e5-44dc-a830-b1de82120305 is one. While testing on the 10.7.2 lab machine I did notice that when I had a few instances of bing maps open that I would get in a state where I had to force quit the browser. This machine has 2 GB of RAM which is a little lean.

(In reply to Scoobidiver from comment #0) > It's a new crash signature that first appeared in 11.0a2/20111222 and > 12.0a1/20111223. (In reply to Ali Juma [:ajuma] from comment #13) > I tried out Firefox 6, and panning/zooming Bing caused Firefox's memory > usage to spike to 3.2 GB, and CPU usage stayed at 100% for about 30 seconds > (Firefox was non-responsive during this time). To Joe's point, the evidence above suggests that this isn't a recent regression in Firefox. We should still investigate this issue, but it's unlikely that we'll take a forward fix in FF11 at this point. Joe - who'd be in the best position to look at Ali's repro case on his computer?

This feels a lot like bug 717521.

(In reply to Joe Drew (:JOEDREW!) from comment #18) > This feels a lot like bug 717521. We landed a backout of the root cause of bug 717521 (bug 702739) on beta in https://bugzilla.mozilla.org/show_bug.cgi?id=717521#c56. Ali - can you try the latest beta build at https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/11.0b6/ to see if you're still able to reproduce?

(In reply to Alex Keybl [:akeybl] from comment #19) > Ali - can you try the latest beta build at > https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/11.0b6/ to see if > you're still able to reproduce? I cannot reproduce the crash on this build, nor do I see any excessive memory usage while panning/zooming Bing maps (memory usage stayed below 325 MB on this build, unlike the 3+ GB I was seeing before).

Thanks Ali! Tentatively marking this as a dupe of bug 717521. If that doesn't end up being the case, please undupe.

Removing qawanted as per the dupe -- please re-add if there is something more QA can do.

(In reply to Alex Keybl [:akeybl] from comment #21) > Thanks Ali! Tentatively marking this as a dupe of bug 717521. If that > doesn't end up being the case, please undupe. I am unduping it. It's #77 top browser crasher in 13.0.1 and #15 in 14.0b7 on Mac OS X. Some comments say: "Was moving browser window to another screen on a multi-display system. Mac OS X Lion" "I was zooming in on a map showing the location of a fire." More crash reports at: https://crash-stats.mozilla.com/report/list?signature=TouchBadMemory+|+mozalloc_abort+|+NS_DebugBreak_P+|+mozilla%3A%3Agl%3A%3AGLContext%3A%3ASetBlitFramebufferForDestTexture

Note that the backout that fixed this (and Bug 717521) was only done for 11. An alternate fix for Bug 717521 landed on 12. Interestingly, the current crashes seem to be happening almost exclusively on the GeForce 320M (in the sample of 35 crash reports I looked at, 34 were on the 320M). The original crash wasn't 320M-specific (e.g. it was also happening on my Radeon HD 6750M).

Is it still reproducible now that bug 827170 is fixed?

(In reply to Scoobidiver from comment #25) > Is it still reproducible now that bug 827170 is fixed? I cannot reproduce it, but note that I also don't think I ever reproduced it after March 2012, so I can't really tell if Bug 827170 made a difference here. My hunch is that these were separate issues -- Bug 827170 was caused by creating textures larger than the maximum texture size, but this bug happened even with textures smaller than the maximum texture size (e.g. see comment 2; a texture of size 10000 by 10000 is rather large, but it isn't larger than the maximum texture size on that machine).

It still happens in 19.0 and 20.0 Beta: https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*+const%29+|+NS_DebugBreak_P+|+mozilla%3A%3Agl%3A%3AGLContext%3A%3ASetBlitFramebufferForDestTexture%28unsigned+int%29 https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*%29+|+NS_DebugBreak_P+|+mozilla%3A%3Agl%3A%3AGLContext%3A%3ASetBlitFramebufferForDestTexture%28unsigned+int%29

More reports at: https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*%29

"Minimal-ish" testcas with a full-size Google Maps map with one map marker. The marker is crucial to the crash. If it is there, rapidly zooming in triggers the crash on my machine. If it is not, the crash never happens. To disable the marker, add #dontcrash to the URL and reload or open in a new tab. (Having the map open with a marker in another tab does not influence the current marker-less tab.) My machine is "MacBookPro3,1" running "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:23.0) Gecko/20130417 Firefox/23.0".

Incidentally, my system information tells me I have an "NVIDIA GeForce 8600M GT" with 256 MB of video RAM.

This might be a long shot, but could it be that once it crashes, subsequent instances of Firefox are more likely to crash? As if there is some "residue" lingering even though the Firefox process has exited/crashed and been restarted completely. When I reboot, things *seem* to be better until it crashes once. After that first crash, they seem to occur more often.

Removing QAwanted since QA can't reproduce this issue locally. I tried on the 07/17 Nightly with bing maps, petco maps and the test case attached to this bug.

Has not happened to me in at least a month, and my testcase no longer crashes the latest nightlies. Can this be closed, even though the latest crash signature update was from June 26?

I think this can be marked as FIXED now, but I don't have the authority to do so.

(In reply to Jan Moesen from comment #34) > I think this can be marked as FIXED now, but I don't have the authority to > do so. Thanks, I double checked the cross-branch rank and there are no instances: https://crash-stats.mozilla.com/topcrasher_ranks_bybug/?bug_number=721667 I'm going to mark this RESOLVED WORKSFORME since we don't know what fixed this specifically.