705641 - Incomplete framebuffer abort in mozilla::layers::LayerManagerOGL::CreateFBOWithTexture with "error 0x8cd6, mFBOTextureTarget 0xde1, aRect.width 2374, aRect.height 656"

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Scoobidiver (away)]

It's a new crash signature that first appeared in 10.0a1/20111105.
It's #7 top crasher on Mac OS X in 10.0a2.

Signature	mozalloc_abort | NS_DebugBreak_P | mozilla::layers::LayerManagerOGL::CreateFBOWithTexture
UUID	d1c3f1a7-cd38-4e01-9ef2-2a1d32111126
Date Processed	2011-11-26 08:25:21.439915
Uptime	14
Last Crash	8.4 minutes before submission
Install Age	43.9 minutes since version was first installed.
Install Time	2011-11-26 15:41:26
Product	Firefox
Version	11.0a1
Build ID	20111122030949
Release Channel	nightly
OS	Mac OS X
OS Version	10.7.2 11C74
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 	Renderers: GL Context? GL Context+
GL Layers? GL Layers+
xpcom_runtime_abort(###!!! ABORT: Error setting up framebuffer --- framebuffer not complete: file /builds/slave/m-cen-osx64-ntly/build/gfx/layers/opengl/LayerManagerOGL.cpp, line 1168)
Processor Notes 	
EMCheckCompatibility	False

Frame 	Module 	Signature [Expand] 	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::layers::LayerManagerOGL::CreateFBOWithTexture 	gfx/layers/opengl/LayerManagerOGL.cpp:1168
3 	XUL 	mozilla::layers::ContainerLayerOGL::RenderLayer 	gfx/layers/opengl/ContainerLayerOGL.cpp:205
4 	XUL 	mozilla::layers::ContainerLayerOGL::RenderLayer 	gfx/layers/opengl/ContainerLayerOGL.cpp:241
5 	XUL 	mozilla::layers::LayerManagerOGL::Render 	gfx/layers/opengl/LayerManagerOGL.cpp:806
6 	XUL 	mozilla::layers::LayerManagerOGL::EndTransaction 	gfx/layers/opengl/LayerManagerOGL.cpp:430
7 	XUL 	nsDisplayList::PaintForFrame 	layout/base/nsDisplayList.cpp:635
8 	XUL 	nsLayoutUtils::PaintFrame 	layout/base/nsLayoutUtils.cpp:1698
9 	XUL 	PresShell::Paint 	layout/base/nsPresShell.cpp:5472
10 	XUL 	nsViewManager::Refresh 	view/src/nsViewManager.cpp:414
11 	XUL 	nsViewManager::DispatchEvent 	view/src/nsViewManager.cpp:885
12 	XUL 	HandleEvent 	view/src/nsView.cpp:159
13 	XUL 	nsChildView::DispatchEvent 	widget/src/cocoa/nsChildView.mm:1521
14 	XUL 	nsChildView::DispatchWindowEvent 	widget/src/cocoa/nsChildView.mm:1531
15 	XUL 	-[ChildView drawRect:inContext:] 	widget/src/cocoa/nsChildView.mm:2562
16 	XUL 	-[ChildView drawRect:] 	widget/src/cocoa/nsChildView.mm:2468
17 	AppKit 	AppKit@0x54fde 	
18 	AppKit 	AppKit@0x4fab7 	
19 	AppKit 	AppKit@0x50ed6 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%20|%20NS_DebugBreak_P%20|%20mozilla%3A%3Alayers%3A%3ALayerManagerOGL%3A%3ACreateFBOWithTexture

Comment 1

[Ali Juma [:ajuma]]

This is caused by Bug 696768.

Comment 2

[Ali Juma [:ajuma]]

For 10, the safest course of action is to simply back out Bug 696768.

For 11, we should add more checks to find out why we're getting an incomplete framebuffer, and then fix that problem.

Comment 3

[Ali Juma [:ajuma]]

Attachment: Back out Bug 696768

This will prevent the crash. As a side effect, it will re-introduce a crash on XUL Fennec with GL Layers on the Nexus S (Bug 695246, which was fixed by Bug 696768), but we don't ship XUL Fennec with GL Layers turned on, so the tradeoff seems to be a good one.

Comment 4

[Asa Dotzler [:asa]]

Comment on attachment 577336 [details] [diff] [review]
Back out Bug 696768

pre-emptive backout approval presuming positive review.

Comment 5

[Ali Juma [:ajuma]]

Attachment: Add reason for framebuffer incompleteness to abort message.

This adds the return value of glCheckFramebufferStatus to the NS_RUNTIMEABORT message (and hence the crash report). This should help us figure out what the real problem is here.

Comment 6

[Ali Juma [:ajuma]]

Attachment 577365 [details] (back out bug 696768) landed on aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/0bfc9ef09601

Comment 7

[Ali Juma [:ajuma]]

(In reply to Ali Juma [:ajuma] from comment #6)
> Attachment 577365 [details] (back out bug 696768) landed on aurora:
> https://hg.mozilla.org/releases/mozilla-aurora/rev/0bfc9ef09601

That should be Attachment 577336 [details] [diff].

Comment 8

[Ali Juma [:ajuma]]

Attachment 578060 [details] [diff] (for gathering more information about the crash) landed on inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/330cc2666567

and on central:
https://hg.mozilla.org/mozilla-central/rev/330cc2666567

Comment 9

[Scoobidiver (away)]

There is still one crash in 11.0a1/20111208 with abort message: "###!!! ABORT: Framebuffer not complete -- error 0x8cdd: file /builds/slave/m-cen-lnx64-ntly/build/gfx/layers/opengl/LayerManagerOGL.cpp, line 1172":
bp-d1d0202f-ef1e-461a-8053-2fe3a2111209

Comment 10

[Ali Juma [:ajuma]]

Error 0x8CDD is GL_FRAMEBUFFER_UNSUPPORTED, which (if taken at face value) means that GL doesn't like the image format(s) we're using in LayerManagerOGL::CreateFBOWithTexture. There's nothing obviously wrong with the image format (we're using GL_RGBA, which should be supported), so we should add some more output to find out if any of the other inputs might be problematic.

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

The way the GLES2 spec is phrased, an implementation is always free to declare a framebuffer GL_FRAMEBUFFER_UNSUPPORTED. The app has to deal with that... I think a correct fallback in this case would be to use non-accelerated layers.

Comment 12

[Ali Juma [:ajuma]]

(In reply to Benoit Jacob [:bjacob] from comment #11)
> The way the GLES2 spec is phrased, ...

FWIW, we're getting this with CGL (on OS X), not with GLES2. For OpenGL, "... the OpenGL specification also requires that implementations support certain formats; that is, if you use these formats, implementations are forbidden to return GL_FRAMEBUFFER_UNSUPPORTED" (http://www.opengl.org/wiki/Framebuffer_Object#Completeness_Rules)

Comment 13

[Ali Juma [:ajuma]]

Attachment: Add more output to framebuffer incompleteness abort message.

Comment 14

[Ali Juma [:ajuma]]

Attachment 580959 [details] [diff] (adding more output) landed on inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/21801345dcaa

The bug should be kept open when this lands on central.

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/21801345dcaa

Comment 16

[Ali Juma [:ajuma]]

There are now a couple crashes (from the same user) where the error is 0x8CD6:
bp-618e4f39-d6e9-4470-888c-590fa2111214
bp-c83b4d03-5a88-47e3-94d0-b0a582111215

This error is GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT. We should include the width and height of the bound texture in the abort message to see if either of these is 0.

Comment 17

[Ali Juma [:ajuma]]

Attachment: Add even more output to framebuffer incompleteness abort message.

Comment 18

[Ali Juma [:ajuma]]

Attachment 582270 [details] [diff] (adding even more output) landed on inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/90dce4939cb3

As before, the bug should be kept open when this lands on central.

Comment 19

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/90dce4939cb3

Comment 20

[Ali Juma [:ajuma]]

Reopening as per Comment 18.

Comment 21

[Scoobidiver (away)]

The abort message is almost the same except aRect.width that varies around 2300.

There are also different values in:
bp-7fda5c3e-9387-4a34-9dbe-ee90b2120208
bp-543a3239-3fa4-46c7-88dc-f6be42120125 (11.0a2)
bp-8028410e-70fb-4d9f-86ce-d4a9c2120124 (11.0a2)
bp-d16c3b78-2c15-418d-8d7b-bae752120210 (11.0a2)
bp-be0a4c66-2f68-4e7f-b3b9-fccc72120117 (11.0a2)

Comment 22

[Oleg Romashin (:romaxa)]

Always reproducible on http://www.cuttherope.ie  page with N9 build, or beagle board build
************ Output ***********
Extensions: EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_NOK_image_shared EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_vg_parent_image EGL_NOKIA_texture_from_pixmap EGL_NOK_texture_from_pixmap EGL_KHR_fence_sync EGL_IMG_context_priority EGL_KHR_lock_surface EGL_KHR_lock_surface2 EGL_NOK_image_yuv EGL_NOK_image_yuv_pixmap EGL_NOK_image_yuv_framebuffer EGL_NOK_image_framebuffer  0x45
Extensions length: 434
>>TextureImageEGL::TextureImageEGL size[480,854]
>>TextureImageEGL::TextureImageEGL size[195,6]
>>TextureImageEGL::TextureImageEGL size[270,6]
Framebuffer not complete -- error 0x8cd6, mFBOTextureTarget 0xde1, aRect.width 480, aRect.height 846

Comment 23

[Oleg Romashin (:romaxa)]

Also I think bug 606794 is related to this problem.

Comment 24

[Oleg Romashin (:romaxa)]

Switching photos in this demo http://www.apple.com/html5/showcase/gallery/
also cause Framebuffer not complete -- error 0x8cd6, mFBOTextureTarget 0xde1, aRect.width 159, aRect.height 178 errors, but without SGX crash.

Comment 25

[Martijn Wargers (dead)]

I guess bug 746730 is related to this?

Comment 26

[Ali Juma [:ajuma]]

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #25)
> I guess bug 746730 is related to this?

Yes, that bug appears to have the same root cause as this one (calling CreateFBOWithTexture with a framebufferRect that's larger than the maximum texture size).

Comment 27

[Matt Woodrow (:mattwoodrow)]

I can reproduce this now (both on tryserver and locally) with my DLBI patches applied.

I think there may be two bugs here, one with an excessively large framebuffer size, and one with reasonable values. I'm hitting the latter.

From https://crash-stats.mozilla.com/report/index/7fda5c3e-9387-4a34-9dbe-ee90b2120208 : aRect.width 87, aRect.height 37

It appears that our call to mGLContext->fBindFramebuffer(LOCAL_GL_FRAMEBUFFER, 0); (in LayerManagerOGL::SetupBackBuffer) is resulting in a framebuffer status of 'GL_FRAMEBUFFER_UNDEFINED'.

From the spec:
"If the target of glCheckFramebufferStatus is the default framebuffer (FBO object number 0 is bound), and the default framebuffer does not exist, then you will get GL_FRAMEBUFFER_UNDEFINED"


This looks similar, and suggests that it's an OS X 10.7 specific issue:
http://stackoverflow.com/questions/9986826/glclear-fails-with-gl-framebuffer-undefined

From this point, all attempts to read/write into the window fail (silently) until we call CreateFBOWithTexture with InitMode_Copy. This creates a new framebuffer, and initializes it with glCopyTexImage2D (which again fails) and leaves the framebuffer without a texture.

I'm also seeing '2012-05-31 16:18:25.052 firefox-bin[87030:110b] invalid drawable' dumped into Terminal before this happens.

Comment 28

[bugecho]

I was redirected to this bug from this crash report.

https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-06-18&signature=TouchBadMemory%20|%20mozalloc_abort%20|%20NS_DebugBreak_P%20|%20mozilla%3A%3Alayers%3A%3ALayerManagerOGL%3A%3ACreateFBOWithTexture&version=Firefox%3A13.0.1

The crash happened when signing-in to icloud.com on Firefox 13 on Mac OS X Snow Leopard.
I have a MacBook 13' with Intel GMA 950 graphics chipset with graphics acceleration turned on. The crash doesn't happen when hardware acceleration in Firefox preferences is turned off. Also when I switch Firefox to full screen with acceleration turned on the screen flickers.

I tried other Firefox versions. I found out that Firefox 13 (stable), Firefox 14 (beta), Firefox 15 (aurora) crash when signing-in to icloud.com. Firefox 16.0a1 (nightly) doesn't crash and I tested it multiple times.

Also Firefox 13 (stable), Firefox 14 (beta) cause the screen to flicker when I switch to full screen mode. Firefox 15 (aurora) and Firefox 16.0a1 (nightly) don't have this problem.

It looks like something changed between Firefox 15 and Firefox 16 that resolved the icloud crashes and the screen flickering on my machine. Is that correct?

Comment 29

[Scoobidiver (away)]

Crash stats say 12.0, 13.0, 14.0b6, 15.0a2 are affected. 16.0a1 is currently unaffected but ADUs are low on Mac in Nightly.
Using your STR, can you find the working range?

Comment 30

[Ali Juma [:ajuma]]

(In reply to bugecho from comment #28)
> It looks like something changed between Firefox 15 and Firefox 16 that
> resolved the icloud crashes and the screen flickering on my machine. Is that
> correct?

Thanks for the detailed report! It sounds like something might have changed in layout so that we're no longer getting layers with visible regions larger than the maximum texture size on icloud.com.

Comment 31

[bugecho]

After trying the testcase in 766422 and signing-in to icloud.com repeatedly I found out that Firefox 16 (nightly) crashes. So I think we must change status-firefox16 to affected.

Comment 32

[Scoobidiver (away)]

There are about 800 crashes in 16.0b5 which makes it #2 top crasher: https://crash-stats.mozilla.com/query?product=FennecAndroid&version=FennecAndroid%3A16.0b5&query_search=signature&query_type=startswith&query=mozalloc_abort |&reason_type=contains&do_query=1

Comment 33

[Scoobidiver (away)]

Right query: https://crash-stats.mozilla.com/query?product=FennecAndroid&version=FennecAndroid%3A16.0b5&query_search=signature&query_type=startswith&query=mozalloc_abort%20|&reason_type=contains&do_query=1

Comment 34

[Lukas Blakk [:lsblakk] use ?needinfo]

Where are you getting this number?  When I look at the crash stats there are several that start with mozalloc_abort but none of them match this signature and the TouchBadMemory signature is no where to be found in 16 or 17 topcrashers.  Can we get more information here about what we're trying to chase down in this re-opened bug and if there are new STR that QA could try on recent builds to confirm that we should still be considering this for tracking?

Comment 35

[Scoobidiver (away)]

(In reply to Lukas Blakk [:lsblakk] from comment #34)
> Where are you getting this number?
It's impossible to do a query which states "contains mozalloc_abort but doesn't contain __swrite (bug 778175 and bug 778175)".
Remove signatures with more than 10 crashes in the query of comment 33 and you will have the right count, thanks to the fix of bug 774622 that hid it in 16.0 Beta up to Beta 3.
It belongs to top 3 with bug 790139 and bug 747629.

Bug 764756 would have helped to aggregate some signatures in order to see it sooner.

Comment 36

[Scoobidiver (away)]

(In reply to Lukas Blakk [:lsblakk] from comment #34)
> if there are new STR that QA could try on recent builds to confirm that we should
> still be considering this for tracking?
Bug 746730 and bug 766422 have a testcase and bug 784277 has STR.

Comment 37

[Martijn Wargers (dead)]

If I understand bug 766422, comment 6, correctly, then the cause is known and a regression window might not be that useful.

Comment 38

[Scoobidiver (away)]

In the mozalloc crash report query filtering crashes with less than 10 reports, I see also "EGL error 3003" error (similar to bug 771774 but different). I need someone mastering awk (Benoît?) to breakdown those aborts.

Comment 39

[Wayne Mery (:wsmwk)]

user at https://github.com/piroor/treestyletab/issues/378#issuecomment-9173877 reports "Disable every extension except TreeStyleTab and GreaseMonkey. Restart FireFox. Press Command+N to open a new windows"

Comment 40

[Lukas Blakk [:lsblakk] use ?needinfo]

Benoit - passing this to you to investigate what our options are here.  We can take speculative fixes in the next two betas, or perhaps there's a possibility for a backout?

Comment 41

[Benoit Jacob [:bjacob] (mostly away)]

If there's question of a backout of this bug, I'd rather let Jeff look into it, as he reviewed the patches here.

Comment 42

[Kelsey Gilbert [:jgilbert]]

Comment 27 seems most useful, especially since it sounds like mattwoodrow can repro this. (or could at one point?) It does indeed sounds like the bug he hit may be because the drawable surface becomes detached somehow. It would be very interesting to see what MOZ_GL_DEBUG (and maybe MOZ_GL_DEBUG_VERBOSE) would show.

Comment 43

[Robert Kaiser]

I don't find those signatures in 17 or higher, is this reproducible in those versions?

Comment 44

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #43)
> I don't find those signatures in 17 or higher, is this reproducible in those
> versions?
Here is the link of comment 33 for 17.0b1: https://crash-stats.mozilla.com/query?product=FennecAndroid&version=FennecAndroid%3A17.0b1&query_search=signature&query_type=startswith&query=mozalloc_abort%20|&reason_type=contains&do_query=1 (remove top 10 signatures not related to this bug)
It's #1 top crasher with about 1250 crashes.

Comment 45

[Robert Kaiser]

(In reply to Scoobidiver from comment #44)
> It's #1 top crasher with about 1250 crashes.

In which list? The list you are linking to here seems bogus, as not all mozalloc_abort crashes are this bug, and no signature in the list you link even has 1250 crashes.

Comment 46

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #45)
> In which list? The list you are linking to here seems bogus
The importing thing in crashes on abort is the abort message, not the crash signature.

> as not all mozalloc_abort crashes are this bug, and no signature in the list you
> link even has 1250 crashes.
About 900 crash signatures with one crash each are related to this bug.
I asked to breakdown crashes by abort message in comment 38 to confirm that. Please, can you do that as you are also an awk master?

Comment 47

[Robert Kaiser]

(In reply to Scoobidiver from comment #46)
> I asked to breakdown crashes by abort message in comment 38 to confirm that.
> Please, can you do that as you are also an awk master?

If you make my days have at least a few more hours then we can start talking about that. Until then, it's something I'd like to do but have no idea how to find time for it.

Comment 48

[Robert Kaiser]

I guess we need Jeff to look into this then, that abort message seems to happen a whole lot in Beta 17 for Android and we really should get something moving here.

Comment 49

[Jeff Muizelaar [:jrmuizel]]

I think jgilbert is a much better position to do something about this than I am. (My reviews were just about information getting, I don't actually have much idea what's going on)

Comment 50

[Kelsey Gilbert [:jgilbert]]

(In reply to Scoobidiver from comment #38)
> In the mozalloc crash report query filtering crashes with less than 10
> reports, I see also "EGL error 3003" error (similar to bug 771774 but
> different). I need someone mastering awk (Benoît?) to breakdown those aborts.

This is EGL_BAD_ALLOC (0x3003), which could contribute to a Missing Attachment error.

0x8CD6 is GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT.

I'll see if I can't reproduce.

Comment 51

[Kelsey Gilbert [:jgilbert]]

It seems like hardly any of the information in this thread is relevant anymore. I need a link to the crashes I'm supposed to be fixing. I can't reproduce anything on nightly on either android or mac.

Comment 52

[Scoobidiver (away)]

Here are crash IDs in the latest Android Nightly, bp-d34dd4b7-8a4f-410a-bf66-86f4c2121102, and in a recent Mac Nightly, bp-9bd08ae3-122f-43b7-8274-b5e622121031.

Comment 53

[Martijn Wargers (dead)]

The testcase from bug 746730 is still crashing. But I don't know if that is related/the same as this bug.
There is also bug 766422 with a testcase.

Comment 54

[Lukas Blakk [:lsblakk] use ?needinfo]

We're now too late in the beta cycle to take speculative fixes and this crash doesn't have one yet anyway.  Please re-nominate if this shows up in the 18 topcrashers, unfortunately we'll have to ship 17 with this.

Comment 56

[Robert Kaiser]

From all I can see right now, this is not a topcrash any more.

Comment 57

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #56)
> From all I can see right now, this is not a topcrash any more.
It's still #1 top crasher in all channels. See comment 44 to 46.

Comment 58

[Robert Kaiser]

Scoobidiver, is this now a dupe of bug 827170, which appears to have fixed this signature?

Comment 59

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #58)
> Scoobidiver, is this now a dupe of bug 827170, which appears to have fixed
> this signature?
I hope so. Let's wait effects after the uplift in Beta and Aurora in case there were other causes than the one assumed in that patch for those crashes.

Comment 60

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #58)
> Scoobidiver, is this now a dupe of bug 827170, which appears to have fixed
> this signature?
It's not a duplicate as there are still crashes on Mac in 19.0b4 (https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort+|+Abort) but none on Android.

Comment 61

[Scoobidiver (away)]

It's #1 top crasher in Firefox 19.0 on Mac OS X.

Every comments talk about logging in to iCloud.

Firefox 20 and above seem unaffected so the fix, whatever it is (it's not the one in bug 827170 already in 19.0), should be uplift to 19.0.1, in case there's one.

Comment 62

[Alex Keybl [:akeybl]]

It's highly unlikely we'll take a fix here in 19.0.1, but we do need to get some QA testing around this bug (our highest OS X priority) to verify that this isn't a more critical issue than we currently believe.

Comment 63

[u279076]

Juan, can you please help by trying to reproduce this issue in our lab?

Comment 64

[juan becerra [:juanb]]

I have been trying to reproduce this on a couple of machines, an old Mac Mini, and my Macbook Air, on 10.6.8, and 10.7.x respectively using Fx19. I've set up an iCloud account with some reminders, notes, and email.
- I try to login/logout/login with my account on iCloud.com
- Send/check email from within the iCloud mail app.
- Visit pages like http://atomsforpeace.info/ and http://atomsforpeace.jp/ and http://hsmaker.com
- Visited redfin.com and looked at different neighborhoods (http://bit.ly/YTyII1)

The majority of the comments say that just login in to icloud.com crashes their browser, but alsto most of the reports I looked at indicate people were using 18.0.1 or 18.0.2. It didn't seem like the people who reported this problem had any add-ons in common, and some didn't have any.

Comment 65

[Cornel Ionce [:noni] [Hubs QA]]

Tried to reproduce this on Mac OS 10.7.5 using Fx 19 with a clean profile and one with lots of add-ons.
I was unable to generate any crash with iCloud. 
Also tried with the websites provided by Juan in comment 64.

Comment 66

[Paul Silaghi, QA [:pauly]]

(In reply to Cornel Ionce [QA] from comment #65)
> Tried to reproduce this on Mac OS 10.7.5 using Fx 19 with a clean profile
> and one with lots of add-ons.
> I was unable to generate any crash with iCloud. 
> Also tried with the websites provided by Juan in comment 64.
No crashes also on Mac OS X 10.6.8 and 10.7.5, FF 19.

Comment 67

[Robert Kaiser]

Just FYI, no correlations for this are being generated, I guess the volume is just too low.

Comment 68

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #67)
> Just FYI, no correlations for this are being generated, I guess the volume
> is just too low.
I disagree.
* Feb 22:
  mozalloc_abort(char const*) | Abort|EXC_BAD_ACCESS / KERN_INVALID_ADDRESS (61 crashes)
     30% (18/61) vs.  19% (284/1503) [e-mail] (Mozilla Labs - Test Pilot, https://addons.mozilla.org/addon/13661)
     25% (15/61) vs.  14% (215/1503) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865)
     18% (11/61) vs.   8% (117/1503) [e-mail] (Firebug, https://addons.mozilla.org/addon/1843)
     13% (8/61) vs.   3% (50/1503) {e4a8a97b-f2ed-450b-b12d-ee082ba24781} (Greasemonkey, https://addons.mozilla.org/addon/748)
      7% (4/61) vs.   1% (19/1503) [e-mail] (YSlow, https://addons.mozilla.org/addon/5369)

* Feb 24:
  mozalloc_abort(char const*) | Abort|EXC_BAD_ACCESS / KERN_INVALID_ADDRESS (50 crashes)
     20% (10/50) vs.   4% (42/1176) {195A3098-0BD5-4e90-AE22-BA1C540AFD1E} (Garmin Communicator, https://addons.mozilla.org/addon/10278)
     10% (5/50) vs.   0% (5/1176) youtubequality@rzll
     10% (5/50) vs.   0% (5/1176) {c8d3bc80-0810-4d21-a2c2-be5f2b2832ac}
     10% (5/50) vs.   1% (6/1176) {a5312b79-bf0d-4825-a25f-b33d67d4a58a}
     10% (5/50) vs.   1% (7/1176) jid1-uabu5A9hduqzCw@jetpack
     10% (5/50) vs.   2% (24/1176) [e-mail]
     12% (6/50) vs.   7% (77/1176) {23fcfd51-4958-4f00-80a3-ae97e717ed8b}

See also bug 836671.

Comment 69

[Robert Kaiser]

(In reply to Scoobidiver from comment #68)
> (In reply to Robert Kaiser (:[e-mail]) from comment #67)
> > Just FYI, no correlations for this are being generated, I guess the volume
> > is just too low.
> I disagree.

Interesting, I didn't find them. That said,m they don't say anything useful/meaningful. Also, are these for Mac for sure and not for Windows?

Comment 70

[Scoobidiver (away)]

As it's fixed in 20.0 and we haven't find the working range in order to uplift the patch in 19.0.1, I don't think it's necessary to continue to QA-work on it.

Comment 71

[u279076]

Dropping qawanted based on comment 70. Please re-add if something needs QA attention.

Comment 72

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

STR in bug 847283.

Comment 73

[Scoobidiver (away)]

There are no crashes in 20.0 and above.