844819 - crash in gfxPlatform::GetSourceSurfaceForSurface with abort message: "Attempt to create unsupported SourceSurface from non-image surface" (Azure only)

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Scoobidiver (away)]

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

Comment 1

[Scoobidiver (away)]

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

Comment 2

[Bas Schouten (:bas.schouten)]

Do we have better steps to reproduce anywhere?

Comment 3

[Scoobidiver (away)]

It's #1 top crasher in MetroFirefox.

Comment 4

[Scoobidiver (away)]

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)."

Comment 5

[Chris Peterson [:cpeterson]]

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

Comment 6

[Scoobidiver (away)]

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

Comment 7

[(not currently active) Ted Mielczarek]

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

Comment 8

[Benoit Girard (:BenWa)]

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

Comment 9

[Benoit Girard (:BenWa)]

Attachment: 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.

Comment 10

[Bas Schouten (:bas.schouten)]

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

Comment 11

[Benoit Girard (:BenWa)]

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

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

Tracking for Metro topcrash.

Comment 13

[Jesse Ruderman]

Does the testcase in bug 779424 help?

Comment 14

[Jesse Ruderman]

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

Comment 16

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 17

[Kyle Wooten]

Thanks!

Comment 18

[Zack Weinberg (:zwol)]

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

Comment 19

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 21

[Daniel Veditz [:dveditz]]

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

Comment 22

[Matt Woodrow (:mattwoodrow)]

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.

Comment 23

[Markus Stange [:mstange]]

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.

Comment 24

[Zack Weinberg (:zwol)]

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.

Comment 25

[Zack Weinberg (:zwol)]

Attachment: possibly malformed GIF

Comment 26

[Benoit Girard (:BenWa)]

Our platform should handle a malform GIF and not crash.

Comment 27

[Markus Stange [:mstange]]

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

Comment 28

[Zack Weinberg (:zwol)]

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

Comment 29

[Markus Stange [:mstange]]

Attachment: Don't attempt to draw empty drawables from SVG.

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.

Comment 30

[Zack Weinberg (:zwol)]

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.

Comment 31

[Markus Stange [:mstange]]

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.

Comment 32

[Daniel Holbert [:dholbert]]

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

Comment 33

[Matt Woodrow (:mattwoodrow)]

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!

Comment 34

[Markus Stange [:mstange]]

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

Comment 35

[u279076]

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 36

[Daniel Holbert [:dholbert]]

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

Comment 37

[Lukas Blakk [:lsblakk] use ?needinfo]

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

Comment 38

[Robert Kaiser]

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

Comment 39

[u279076]

(In reply to Robert Kaiser (:[e-mail]) 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.

Comment 40

[u279076]

PS

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

Comment 41

[Leonard Camacho [:lcamacho]]

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.

Comment 42

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 43

[Matt Woodrow (:mattwoodrow)]

Attachment: Don't create DrawTargets for cairo error surfaces

https://tbpl.mozilla.org/?tree=Try&rev=a6068975c803

Comment 44

[u279076]

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

Comment 45

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/89c119add892

Comment 46

[Marcia Knous [:marcia]]

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

Comment 47

[u279076]

Thanks Marcia, can you try this build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-a6068975c803/try-macosx64/firefox-27.0a1.en-US.mac.dmg

Comment 48

[Chris Peterson [:cpeterson]]

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.

Comment 49

[u279076]

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.

Comment 50

[Zack Weinberg (:zwol)]

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.

Comment 51

[u279076]

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

Comment 52

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/89c119add892

Comment 54

[Bogdan Maris, Desktop QA]

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.

Comment 55

[Lukas Blakk [:lsblakk] use ?needinfo]

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

Comment 56

[Lukas Blakk [:lsblakk] use ?needinfo]

Matt - can you prepare the uplift nominations for this?

Comment 57

[Matt Woodrow (:mattwoodrow)]

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 58

[Lukas Blakk [:lsblakk] use ?needinfo]

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

Comment 59

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/2a42d4d730da

Comment 60

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/2a42d4d730da

Comment 61

[Evan Wallace [:evanw]]

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.

Comment 64

[Bogdan Maris, Desktop QA]

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

Comment 66

[Dan Carr]

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.

Comment 67

[Daniel Holbert [:dholbert]]

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.

Comment 68

[Dan Carr]

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!

Comment 69

[Dan Carr]

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?

Comment 70

[Dan Carr]

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.