It occurs mainly on Windows 8, including Metro. Here is a comment: "I was unable to logon/pull up two websites: http://specialexcitingoffers.com; and http://yvoneinternetdeals.com/" Signature mozalloc_abort(char const* const) | NS_DebugBreak_P | gfxPlatform::GetSourceSurfaceForSurface(mozilla::gfx::DrawTarget*, gfxASurface*) More Reports Search UUID 982e5862-055f-472c-b349-342162130225 Date Processed 2013-02-25 06:20:18 Uptime 1555 Install Age 11.4 hours since version was first installed. Install Time 2013-02-24 18:53:42 Product MetroFirefox Version 22.0a1 Build ID 20130223031157 Release Channel nightly OS Windows NT OS Version 6.2.9200 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 42 stepping 7 Crash Reason EXCEPTION_BREAKPOINT Crash Address 0x7139198a User Comments App Notes AdapterVendorID: 0x1002, AdapterDeviceID: 0x6841, AdapterSubsysID: 00000000, AdapterDriverVersion: 8.97.10.6 D2D! D2D+ DWrite? DWrite+ D3D10 Layers! D3D10 Layers+ xpcom_runtime_abort(###!!! ABORT: Attempt to create unsupported SourceSurface fromnon-image surface.: file e:/builds/moz2_slave/m-cen-w32-ntly-000000000000000/build/gfx/thebes/gfxPlatform.cpp, line 645) Processor Notes sp-processor05.phx1.mozilla.com_20098:2008; WARNING: JSON file missing Add-ons EMCheckCompatibility True Adapter Vendor ID 0x1002 Adapter Device ID 0x6841 Total Virtual Memory 4294836224 Available Virtual Memory 3783475200 System Memory Use Percentage 35 Available Page File 6592176128 Available Physical Memory 2736062464 Accessibility Active Frame Module Signature Source 0 mozalloc.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:30 1 xul.dll NS_DebugBreak_P xpcom/base/nsDebugImpl.cpp:409 2 xul.dll gfxPlatform::GetSourceSurfaceForSurface gfx/thebes/gfxPlatform.cpp:645 3 xul.dll gfxPattern::GetPattern gfx/thebes/gfxPattern.cpp:170 4 xul.dll GeneralPattern::operator mozilla::gfx::Pattern& gfx/thebes/gfxContext.cpp:47 5 xul.dll gfxContext::FillAzure gfx/thebes/gfxContext.cpp:2023 6 xul.dll gfxSurfaceDrawable::Draw gfx/thebes/gfxDrawable.cpp:133 7 xul.dll gfxUtils::DrawPixelSnapped gfx/thebes/gfxUtils.cpp:483 8 xul.dll nsLayoutUtils::DrawPixelSnapped layout/base/nsLayoutUtils.cpp:4044 9 xul.dll nsRect::ScaleToOutsidePixels gfx/src/nsRect.h:314 10 xul.dll nsImageRenderer::Draw layout/base/nsCSSRendering.cpp:4678 11 xul.dll nsCSSRendering::PaintBackgroundWithSC layout/base/nsCSSRendering.cpp:2676 12 xul.dll nsCSSRendering::PaintBackground layout/base/nsCSSRendering.cpp:1572 13 xul.dll nsDisplayBackgroundImage::Paint layout/base/nsDisplayList.cpp:2119 14 xul.dll mozilla::FrameLayerBuilder::DrawThebesLayer layout/base/FrameLayerBuilder.cpp:3341 15 xul.dll mozilla::layers::ThebesLayerD3D10::DrawRegion gfx/layers/d3d10/ThebesLayerD3D10.cpp:449 More reports at: https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*+const%29+|+NS_DebugBreak_P+|+gfxPlatform%3A%3AGetSourceSurfaceForSurface%28mozilla%3A%3Agfx%3A%3ADrawTarget*%2C+gfxASurface*%29

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

Do we have better steps to reproduce anywhere?

It's #1 top crasher in MetroFirefox.

Here are some comments: "Hey, I think I found a crash thing. If you're in grouped tab mode, or whatever it's called, and you connect or disconnect another monitor, Firefox crashes." "just clicked on tab groups and it crashed." "Don't know if it's related, but this happened right before or right after the laptop hibernated" "Nvidia driver 320.18 crashed along with Firefox. (I hear the drivers are really buggy even in games)."

Scoobidiver: why is the `[@ mozalloc_abort(char const*) | NS_DebugBreak | RDFServiceImpl::GetAnonymousResource(nsIRDFResource**)::gChars ]` crash signature related to this gfxPlatform::GetSourceSurfaceForSurface() crash?

(In reply to Chris Peterson (:cpeterson) from comment #5) > Scoobidiver: why is the `[@ mozalloc_abort(char const*) | NS_DebugBreak | > RDFServiceImpl::GetAnonymousResource(nsIRDFResource**)::gChars ]` crash > signature related to this gfxPlatform::GetSourceSurfaceForSurface() crash? The stack trace is buggy but the abort message for one of them is the same. See bp-bee33154-0d86-4c5e-bca7-2942c2130715. Most crashes with this signature are bug 886667. Ted, is the buggy stack trace again bug 884300?

That doesn't make sense to me, since the crash you just linked is from a recent Nightly, so that issue should be fixed.

Reproducible on mac nightly for me: http://www.owlfolio.org/travelogues/postcard-from-l-a

Reproduced in a debugger: http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPlatform.cpp#736 aSurface is a gfxQuartzSurface, so calling aSurface->GetAsImageSurface returns a different object and thus 'imgSurface != aSurface && !isWin32ImageSurf' fails triggering the abort. Looks like your patch didn't account Quartz.

(In reply to Benoit Girard (:BenWa) from comment #9) > Created attachment 788630 [details] > Debug session > > Reproduced in a debugger: > http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPlatform.cpp#736 > > aSurface is a gfxQuartzSurface, so calling aSurface->GetAsImageSurface > returns a different object and thus 'imgSurface != aSurface && > !isWin32ImageSurf' fails triggering the abort. > > Looks like your patch didn't account Quartz. Quartz content didn't exist at the time so this is quite possible :). Jeff?

I hit this in a new page: http://www.ideo.com/work/atm-interface

Tracking for Metro topcrash.

Does the testcase in bug 779424 help?

In Nightly 26, the correct signature for this bug is 0.29% of crashes, with other signatures at 0.22% and 0.1%.

Crashes on http://www.owlfolio.org/research/some-trivia-about-the-alexa-1m/ (from duped bug 922806)

Thanks!

cc:ing myself since it seems to happen reliably on my own blog :-)

Matt or Bas, while we're waiting for Jeff to come back from PTO, anything to add?

(In reply to Bas Schouten (:bas.schouten) from comment #2) > Do we have better steps to reproduce anywhere? attachment 813977 [details] from bug 923977 is a reliable testcase for some people on Mac.

We only should ever hit that path if CreateSourceSurfaceFromData has failed, which (on mac at least) on fails if our attempt to create the CGImage failed. Looking at bug 923977 and bug 779424, it would appear that we're just trying to use a ridiculously large surface, bigger than quartz supports. So either this is an invalid assertion (we should just not draw it), or we need to implement some sort of tiling to handle massive source surfaces.

On Zack's blog CGImage creation fails because the image is zero-sized; I see this before crashing: firefox-bin[94352] <Error>: CGImageCreate: invalid image size: 0 x 0.

Aha! That points a finger at Piwik, which does the typical 1x1 GIF thing to post analytics back to the server... $ curl -s -v -o piwik.gif "http://www.owlfolio.org/rodstasdt/piwik.php?action_name=Owl%E2%80%99s%20Por%E2%80%A6lp=0&wma=0&dir=0&fla=1&java=1&gears=0&ag=1&cookie=1&res=1280x800&gt_ms=249" && hexdump -C piwik.gif > GET /rodstasdt/piwik.php?action_name=Owl%E2%80%99s%20Por%E2%80%A6lp=0&wma=0&dir=0&fla=1&java=1&gears=0&ag=1&cookie=1&res=1280x800&gt_ms=249 HTTP/1.1 > User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8y zlib/1.2.3 > Host: www.owlfolio.org > Accept: */* > < HTTP/1.1 200 OK < Date: Wed, 09 Oct 2013 21:41:35 GMT < Server: Apache < Cache-Control: max-age=1 < Expires: Wed, 09 Oct 2013 21:41:36 GMT < Content-Type: text/html; charset=utf-8 < Transfer-Encoding: chunked < Via: 1.1 vhost.phx1.nearlyfreespeech.net:3128 (squid/2.7.STABLE7) < 00000000 47 49 46 38 39 61 01 00 01 00 80 00 00 00 00 00 |GIF89a..........| 00000010 00 00 00 21 f9 04 01 00 00 00 00 2c 00 00 00 00 |...!.......,....| 00000020 01 00 01 00 00 02 02 44 01 00 3b |.......D..;| 0000002b I don't have any good way of knowing whether that is a *valid* 1x1 GIF, but I note that the Content-Type of the response is bogus. I'm going to disable Piwik on my blog so it stops crashing the browser when I try to use it :) but let me know if you want me to test anything.

Our platform should handle a malform GIF and not crash.

My debugger tells me that the culprit is an SVG image. I'll have a patch shortly.

(In reply to Benoit Girard (:BenWa) from comment #26) > Our platform should handle a malform GIF and not crash. Certainly; I'm just pleased to have a workaround. ... except that disabling the analytics software didn't help; the front page (http://www.owlfolio.org/) still crashes for me, even after flushing both server- and client-side caches. https://crash-stats.mozilla.com/report/index/6533c029-013a-46f8-a013-bdc612131009 is after disabling piwik. /me out of clever ideas. :-/

This fixes the owlfolio crash for me. I can't reproduce crashes on the other testcases. It probably won't fix them, and we probably should have more protections against zero-sized surfaces in place, but I'm not sure at what point they should go.

Do you have the URL of the offending SVG image? I'm pretty sure whatever it is, it isn't supposed to be like that.

It's http://www.owlfolio.org/wp-content/themes/owlfolio/s/bg893.svg which has height == 1, but in the code that my patch changes, scale.height is 2.3533333702709944 during the crashing case, so drawableSize.height is zero.

Hmm. I wonder if we should instead be disabling the scale in this case? (or clamping the drawableSize somehow) I think this scaling code is mostly concerned with scaling up (to make sure we rasterize at a high resolution), but I'm not sure we want it to end up inadvertently giving us 0-size drawables. Seems like it might be better not to scale in that case. Setting that aside, though; is it really reasonable for us to crash if we request a 0-sized drawable? If I force drawableSize to have 0 height in GDB (while viewing the owlfolio front page) in Linux, nothing explodes. Why can't we be that graceful on Windows, too? :)

Because we're using cairo on linux (via Moz2D). Cairo handles errors fairly silently by just returning a fake surface object that won't actually do anything useful. The crash occurs when trying to 'convert' a Thebes/Cairo surface into it's Moz2D equivalent. On linux we're converting into Moz2D/cairo, which just pipes the cairo object through, without noticing that it's an error surface. On other platforms we're using other Moz2D backends (like Moz2D/coregraphics, or Moz2D/direct2d) and we need to grab the underlying platform specific object, or a pointer to the raw data (depending on what the source was). This fails, since the error surface we're using as a source doesn't actually have these things. We then handle this poorly, and crash :) Assuming my explanation actually covers all cases in which we crash, we can easily check for the error surface at the top of GetSourceSurfaceForSurface and return nullptr. We'd also need to make sure that all callers of this function can handle that it won't always succeed!

The surface we get passed to GetSourceSurfaceForSurface is not actually an error surface, though. Its CGContextRef is null, but its CairoStatus() is zero (i.e. not in error).

I was looking at the explosiveness of this crash on Firefox 25 Beta and it seems to have spiked in recent days. Starting on Oct 8, 2013 we hit ~41.9 crashes per 1M ADU compared to a median of 11.3 crashes per 1M ADU the previous 7 days. Do we know if there were any changes recently which might account for this?

Comment on attachment 815119 [details] [diff] [review] Don't attempt to draw empty drawables from SVG. (In reply to Markus Stange [:mstange] from comment #34) > The surface we get passed to GetSourceSurfaceForSurface is not actually an > error surface, though. OK; back to the question at the end of Comment 32, then. :) Can we play nicely with this non-error surface (or something like that) such that we don't crash? Marking current patch as r-, at least for this bug, since I think we need to fix this at a lower level. (That'll have a higher chance of fixing the non-SVG cases, too.) (If it turns out that playing nicely with the surface is really hard for some reason, then we can reconsider this approach.) (It might be worth taking this patch as a non-functinoal optimization, but I'm not convinced it's worth it, since I don't think this is a particularly common use-case & hence probably not something to optimize for.)

Metro is not going forward to Beta for FF26 so removing tracking.

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #35) > I was looking at the explosiveness of this crash on Firefox 25 Beta and it > seems to have spiked in recent days. Which signature is that? Have you checked that those crashes have this abort message?

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #38) > (In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #35) > > I was looking at the explosiveness of this crash on Firefox 25 Beta and it > > seems to have spiked in recent days. > > Which signature is that? Have you checked that those crashes have this abort > message? The signature was mozalloc_abort(char const*) | Abort | NS_DebugBreak | gfxPlatform::GetSourceSurfaceForSurface(mozilla::gfx::DrawTarget*, gfxASurface*) however this seems to have dropped off now in explosiveness.

PS The crashes did have the abort message "Attempt to create unsupported SourceSurface from non-image surface", but again this is no longer explosive.

I don't know if this helps but this crash happens to me when I try to go to this link http://www.owlfolio.org/possibly-useful/flex-input-scanner-rules-are-too-complicated/ I'm using latest nightly on OS X Mavericks.

This is now the #1 Mac topcrash on the 26 branch and the #3 topcrash on the 27 branch. I'll see if I can reproduce using lcamacho's STR from comment #41.

(In reply to Steven Michaud from comment #42) > This is now the #1 Mac topcrash on the 26 branch and the #3 topcrash on the 27 branch. Given this I suggest we reconsider tracking. Marcia, do you think you could try reproducing this in OSX Mavericks based on comment 41?

I can reproduce the crash on both the latest Nightly and latest Aurora easily using the link in Comment 41. https://crash-stats.mozilla.com/report/index/950132e4-dfb3-411f-b126-5db912131024

Thanks Marcia, can you try this build: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mwoodrow@mozilla.com-a6068975c803/try-macosx64/firefox-27.0a1.en-US.mac.dmg

ashughes: using the test from comment 41, I can reproduce the crash in the latest Nighty 27, but not in the try build from comment 47.

Thanks Chris. Matt, based on Chris' testing of your try build it would seem that you've at least fixed the comment 41 case. Lets see if it has any impact on this crash after some time on Nightly.

FYI, I'm about to redo the styling on owlfolio.org to eliminate the offending SVG background images (because I'm tired of having my own blog crash my browser). I can reproduce easily on my Mac, so please let me know if it would be useful for me to produce a self-contained test case.

(In reply to Zack Weinberg (:zwol) from comment #50) > let me know if it would be useful for me to produce a self-contained test case. Yes please do and attach to this bug if you can, for posterity.

I was able to reproduce the crash on Mac OS X 10.9 with help from bug 923977 on a build before the fix with signature: mozalloc_abort(char const*) | Abort | NS_DebugBreak | gfxPlatform::GetSourceSurfaceForSurface(mozilla::gfx::DrawTarget*, gfxASurface*) https://crash-stats.mozilla.com/report/index/0ede3d01-7047-4965-8b41-980172131106 Unable to crash latest Aurora 27.0a2 and latest Nightly 28.0a1 on Mac but after loading TC from bug 923977 I get a black page which I don`t think that`s expected. Should I log a new bug for that? Socorro does not display any crashes on 27.0a2 in the last 2 weeks with the signature from above. https://crash-stats.mozilla.com/query/?product=Firefox&version=Firefox%3A27.0a2&platform=win&platform=mac&platform=lin&range_value=2&range_unit=weeks&date=11%2F06%2F2013+15%3A00%3A00&query_search=signature&query_type=contains&query=mozalloc_abort%28char+const*%29+%7C+Abort+%7C+NS_DebugBreak+%7C+gfxPlatform%3A%3AGetSourceSurfaceForSurface&reason=&release_channels=&build_id=&process_type=any&hang_type=any Based on the above I am marking this as verified fixed.

If this is verified fixed, let's get uplift noms ready so this might make it into tomorrow's Beta and allow us to collect more crash data before shipping FF26

Matt - can you prepare the uplift nominations for this?

Comment on attachment 821102 [details] [diff] [review] Don't create DrawTargets for cairo error surfaces [Approval Request Comment] Bug caused by (feature/regressing bug #): Unknown, Azure content somewhere User impact if declined: Crashes with some content Testing completed (on m-c, etc.): Been on m-c for a week Risk to taking this patch (and alternatives if risky): Very low risk, just a null check String or IDL/UUID changes made by this patch: None

Comment on attachment 821102 [details] [diff] [review] Don't create DrawTargets for cairo error surfaces This is already verified on 27, so just approving for Beta

This is now in Firefox stable and took me a while to figure out. For people looking for a workaround for the next few months, make sure your SVG backgrounds are at least 3px in size.

Verified as fixed on Firefox 26 beta 5. Based on Socorro there are no crashes in beta build later then the push. https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const%2A%29+%7C+Abort+%7C+NS_DebugBreak+%7C+gfxPlatform%3A%3AGetSourceSurfaceForSurface%28mozilla%3A%3Agfx%3A%3ADrawTarget%2A%2C+gfxASurface%2A%29&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&platform=win&platform=mac&platform=lin&version=Firefox%3A26.0b&hang_type=any&date=2013-11-06+15%3A00%3A00&range_value=2#reports

Hey guys. I'm getting this crash occurring when I got to this page: http://dancarrphotography.com/blog/2013/04/05/mindshift-gears-new-rotation-180-pro-full-review/ I have downloaded the 26 Beta and confirm that the crash does not occur with 26. However, I really need to get this page working again so can someone tell me what it is on that page that is causing the crash? I have no SVG images on it and no Gifs. I'll be honest, some of what you guys are talking about has gone way over my head. If someone could help me fix that page so it works with 25 then it would be great. Every other page on my site seems to work fine so it's something specific to that page somewhere.

Dan: I believe this means you have a malformed image on your page. You could try moving all the images to another directory (on your web server) -- which will hopefully fix the crash -- and then moving half of them back, and then half again, etc. until you hit the crash again. And then narrowing from there should tell you which image is at fault.

Ah ok thanks Daniel. I won't pretend to know exactly what a malformed image is but I'll certainly take them all down and add them back one by one. That makes sense to me. Thanks!

It seems this is more complicated than one particular image that's causing the issue. It's actually dependant on the length of my post. For the last hour or so I've been trying to figure this out. There'a s point in my post at which I can safely get to while re-posting the content, about half way down it. If I delete everything below that point, it loads fine. However if I add ANYTHING below this point it causes the crash. I can be an image, it can be some text. It doesn't even have to be any of the original text. I tested it by just posting 5 paragraphs of Lorem Ipsum and that still caused the crash. So it has something to do with the length of the post. My crash reports always mention line 732. Could that have something to do with it?

To follow up further on this I tracked an issue down to the standard Facebook 'Like' button in the large size after systematically removing elements of my site. It seems odd, but as soon as I removed that button from my page the problems stopped and Firefox no longer crashed. The 'small' Facebook buttons seem to work fine. I've no idea why that should be linked to the length of the post though as I described in the previous comment.