Closed Bug 612090 Opened 15 years ago Closed 15 years ago

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

Categories

(Core :: Widget: Cocoa, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla2.0b8
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: scoobidiver, Assigned: mstange)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

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
blocking2.0: --- → ?
Markus, do you have time to look at this?
Assignee: nobody → mstange
blocking2.0: ? → betaN+
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+
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]
Status: NEW → RESOLVED
Closed: 15 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.

Attachment

General

Created:
Updated:
Size: