Firefox 4.0b7 crash [@ nsBaseWidget::AutoUseBasicLayerManager::AutoUseBasicLayerManager ]

RESOLVED FIXED in mozilla2.0b8

Status

()

Core
Widget: Cocoa
--
critical
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: Scoobidiver (away), Assigned: mstange)

Tracking

({crash})

Trunk
mozilla2.0b8
x86_64
Mac OS X
crash
Points:
---

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
It is a crash signature in 4.0b7 on Mac OS X 64-bit.
It is #7 top crasher on Mac OS X in 4.0b7 for the last week.

Signature	nsBaseWidget::AutoUseBasicLayerManager::AutoUseBasicLayerManager
UUID	2d86278b-b9d5-405f-a3d5-360d62101113
Time 	2010-11-13 13:54:44.88562
Uptime	37332
Last Crash	1725930 seconds (2.9 weeks) before submission
Install Age	99415 seconds (1.2 days) since version was first installed.
Product	Firefox
Version	4.0b7
Build ID	20101104131842
Branch	2.0
OS	Mac OS X
OS Version	10.6.3 10D573
CPU	amd64
CPU Info	family 6 model 23 stepping 6
Crash Reason	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address	0x86
App Notes 	Renderers: 0x22600,0x20400

Frame 	Module 	Signature [Expand] 	Source
0 	XUL 	nsBaseWidget::AutoUseBasicLayerManager::AutoUseBasicLayerManager 	widget/src/xpwidgets/nsBaseWidget.cpp:768
1 	XUL 	-[ChildView drawRect:inTitlebarContext:] 	widget/src/cocoa/nsChildView.mm:2625
2 	XUL 	ContentPatternDrawCallback 	widget/src/cocoa/nsCocoaWindow.mm:2436
3 	CoreGraphics 	CoreGraphics@0x1f3b9d 	
4 	libRIP.A.dylib 	libRIP.A.dylib@0x203a2 	
5 	libnspr4.dylib 	PR_ExitMonitor 	nsprpub/pr/src/pthreads/ptsynch.c:589
6 	XUL 	CallMethodHelper::~CallMethodHelper 	nsTArray.h:274 

More reports at:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=nsBaseWidget%3A%3AAutoUseBasicLayerManager%3A%3AAutoUseBasicLayerManager&version=Firefox%3A4.0b7
(Reporter)

Updated

8 years ago
blocking2.0: --- → ?
Markus, do you have time to look at this?
Assignee: nobody → mstange
blocking2.0: ? → betaN+
(Assignee)

Comment 2

8 years ago
Created attachment 490839 [details] [diff] [review]
null-check mGeckoChild
Attachment #490839 - Flags: review?(joe)
Comment on attachment 490839 [details] [diff] [review]
null-check mGeckoChild

This is probably some sort of race between initWithFrame/widgetDestroyed and drawRect: being called, right?
Attachment #490839 - Flags: review?(joe) → review+
(Assignee)

Comment 4

8 years ago
Yeah, it has to do with delayedTearDown, I think. nsChildView::Destroy() first calls widgetDestroyed, which sets mGeckoChild on the NSView to null, and then TearDownView which schedules a call to delayedTearDown. Until delayedTearDown is called, the NSView still survives, so drawRect: can be called in the meantime.
Keywords: checkin-needed
Whiteboard: [can land]

Comment 5

8 years ago
http://hg.mozilla.org/mozilla-central/rev/4eeb36eb555f
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [can land]
Target Milestone: --- → mozilla2.0b8
Crash Signature: [@ nsBaseWidget::AutoUseBasicLayerManager::AutoUseBasicLayerManager ]
You need to log in before you can comment on or make changes to this bug.