813024 - crash in mozilla::layers::BasicLayerManager::SetDefaultTarget

Status: RESOLVED FIXED

(Core :: Widget, defect)

Description

[Scoobidiver (away)]

It's #5 top crasher (#3 non fixed) in 19.0a1 on Mac OS X.
It first showed up in 19.0a1/20121026. The regression window might be (discontinuous across builds):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5c82f5a5e90d&tochange=5ecff3e46ed5

It might be related to bug 805745 (similar first frames and regression window).

Signature 	mozilla::layers::BasicLayerManager::SetDefaultTarget(gfxContext*) More Reports Search
UUID	94e22e90-16cd-4940-8a9f-bc8e22121117
Date Processed	2012-11-17 17:11:47
Uptime	2
Last Crash	24 seconds before submission
Install Age	1.1 days since version was first installed.
Install Time	2012-11-16 15:22:19
Product	Firefox
Version	19.0a1
Build ID	20121116030725
Release Channel	nightly
OS	Mac OS X
OS Version	10.7.5 11G63
Build Architecture	amd64
Build Architecture Info	family 6 model 37 stepping 5
Crash Reason	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address	0xa00
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x68c0GL Context? GL Context+ GL Layers? GL Layers+ 
EMCheckCompatibility	True
Adapter Vendor ID	0x1002
Adapter Device ID	0x68c0

Frame 	Module 	Signature 	Source
0 	XUL 	mozilla::layers::BasicLayerManager::SetDefaultTarget 	dist/include/nsISupportsImpl.h:276
1 	XUL 	nsBaseWidget::AutoLayerManagerSetup::~AutoLayerManagerSetup 	nsBaseWidget.cpp:756
2 	XUL 	-[ChildView drawRect:inContext:alternate:] 	nsChildView.mm:2517
3 	XUL 	-[ChildView drawRect:inTitlebarContext:] 	nsChildView.mm:2411
4 	XUL 	TitlebarDrawCallback 	nsCocoaWindow.mm:2913
5 	CoreGraphics 	CoreGraphics@0x251e74 	
6 	libRIP.A.dylib 	libRIP.A.dylib@0x1b886

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Alayers%3A%3ABasicLayerManager%3A%3ASetDefaultTarget%28gfxContext*%29

Comment 1

[Robert Kaiser]

There's 23 crashes overall with this signature, a lot of those dupes, not sure if this is more than 3-4 people seeing this crash at all. Might be worth a look if there's something one can spot with easy code inspection, but not sure we need to track at this stage.

Comment 2

[Alex Keybl [:akeybl]]

Let's wait to see if this persists on Aurora.

Comment 3

[Shyam Mani [:fox2mike]]

(In reply to Alex Keybl [:akeybl] from comment #2)
> Let's wait to see if this persists on Aurora.

I upgraded my Aurora from 18 to 19 today and I couldn't launch the browser without crashing it :| 

So after 4-5 crashes, I'm finally using it..and looking at this report.

https://crash-stats.mozilla.com/report/index/bp-514f46b7-2b6e-442c-93ad-0cc052121128

Comment 4

[Shyam Mani [:fox2mike]]

Also, startup time is much higher on 19.0a compared to the previous one. Magnitude of a more than few seconds

Comment 5

[Alex Keybl [:akeybl]]

(In reply to Shyam Mani [:fox2mike] from comment #4)
> Also, startup time is much higher on 19.0a compared to the previous one.
> Magnitude of a more than few seconds

Please file a separate bug for the startup perf issue you're running into. Now that we've had somebody internally run into this crash, makes sense to investigate. Throwing this one over to roc to help find an assignee.

Note: this is mac only right now.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It does look a lot like a Mac version of bug 805745. Let's hope Timothy can fix that.

Comment 7

[Josh Matthews [:jdm]]

I hit this and was unable to start Firefox with my default profile until I opened it in safe mode.

Comment 8

[Timothy Nikkel (:tnikkel)]

Should be fixed by bug 805745.

Comment 9

[Scoobidiver (away)]

It's not fixed. There are still crashes after the patch of bug 805745 landed.

Comment 10

[Timothy Nikkel (:tnikkel)]

Could you point me to those crashes? I can't find them. Note that the first nightly that has bug 805745 is 2012-12-14 (it didn't make the m-c merge for 2012-12-13).

Comment 11

[Scoobidiver (away)]

(In reply to Timothy Nikkel (:tn) from comment #10)
> Could you point me to those crashes?
Follow the link in comment 0. It seems even worse than before.

Comment 12

[Timothy Nikkel (:tnikkel)]

Ok, interesting. Those didn't show up following the link for it from the top crashes.

Those crashes are all in alternate paints, which is Mac only. I'll look into it.

Comment 13

[Scoobidiver (away)]

The spike in 20.0a1/20121214 is caused by bug 805745.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This is preventing me from starting nightly at all and is 100% reproducible. I'll see if I can reproduce with a debug build.

Comment 15

[Josh Matthews [:jdm]]

Likewise, I hit this on nightly and had to use safe mode to be able to start the browser.

Comment 16

[Timothy Nikkel (:tnikkel)]

It seems like this new crash is worse then what is fixed by the offending patch from bug 805745 so I'll back it out until we have a fix for this.

Comment 17

[Josh Matthews [:jdm]]

Attachment: Backtrace

From an up-to-date debug build.

Comment 18

[Josh Matthews [:jdm]]

Attachment: Problem stack

Here's the problem: we perform a paint, and when we run scripts we end up running a sync XHR which causes a nested paint to begin.

Comment 19

[Timothy Nikkel (:tnikkel)]

Attachment: patch

So this just makes us do the right thing if we have nested painting calls and hence nested AutoUseBasicLayerManager's. It would be nice if we could get rid of all nested painted, but I'm not sure if that is possible, and we'll want a branch patch for this issue anyway.

Comment 20

[Timothy Nikkel (:tnikkel)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/82d45d6f8964

Comment 21

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/82d45d6f8964

Comment 22

[Josh Matthews [:jdm]]

Hmm, I'm continuing to crash on startup in nightly builds: https://crash-stats.mozilla.com/report/index/bp-303f0f41-dc05-4e5e-bb55-70d512121217

Comment 23

[Timothy Nikkel (:tnikkel)]

This patch didn't make the 2012-12-17 nightly, so that is expected.

Comment 24

[Timothy Nikkel (:tnikkel)]

Comment on attachment 692817 [details] [diff] [review]
patch

We want this because bug 805745 makes this bug worse.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): not sure, the problematic code exists at least as far back as 18 
User impact if declined: crashes in some situations with certain addons
Testing completed (on m-c, etc.): been on nightly
Risk to taking this patch (and alternatives if risky): this is a straight forward patch that clearly does the right thing
String or UUID changes made by this patch: none

Comment 25

[Timothy Nikkel (:tnikkel)]

https://hg.mozilla.org/releases/mozilla-beta/rev/206cde601341

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/e32b6c246cca

Comment 27

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/206cde601341

Comment 28

[Timothy Nikkel (:tnikkel)]

Comment on attachment 692817 [details] [diff] [review]
patch

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: want this so that bug 805745 doesn't have any chance of making crashes more frequent
User impact if declined: maybe some amount of crashes
Fix Landed on Version: 18, 19, 20
Risk to taking this patch (and alternatives if risky): simple straight forward patch
String or UUID changes made by this patch: none

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr17/rev/e11ce395fa6c

Comment 30

[Ioana (away)]

There are no crashes post-fix on any builds:
https://crash-stats.mozilla.com/report/list?query_search=signature&query_type=contains&reason_type=contains&range_value=4&range_unit=weeks&hang_type=any&process_type=any&signature=mozilla%3A%3Alayers%3A%3ABasicLayerManager%3A%3ASetDefaultTarget%28gfxContext%2A%29