Closed Bug 839752 Opened 12 years ago Closed 11 years ago

startup crash in nsCocoaWindow::Show @ ripc_GetColor

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Version:
19 Branch
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox19 --- affected
firefox20 --- affected

People

(Reporter: scoobidiver, Unassigned)

Details

(Keywords: crash, regression, Whiteboard: [startupcrash])

Crash Data

It has been hit by three users at startup in 19.0b5 where it first showed up. If applicable, the regression range is: http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=e815122c4b1f&tochange=3e382bb14817 I suspect bug 836887 with a combination of some themes. Signature ripc_GetColor More Reports Search UUID 213ac5c3-e203-4bbd-a950-3bbfd2130209 Date Processed 2013-02-09 00:15:23 Uptime 3 Last Crash 18.4 minutes before submission Install Age 15.3 hours since version was first installed. Install Time 2013-02-08 08:55:51 Product Firefox Version 19.0 Build ID 20130206083616 Release Channel beta OS Mac OS X OS Version 10.6.8 10K549 Build Architecture amd64 Build Architecture Info family 6 model 23 stepping 10 Crash Reason EXC_BAD_ACCESS / 0x0000000d Crash Address 0x0 User Comments Keeps crashing at start up App Notes AdapterVendorID: 0x10de, AdapterDeviceID: 0x 869GL Context? GL Context+ GL Layers? GL Layers+ Processor Notes sp-processor06.phx1.mozilla.com_8157:2008; exploitablity tool: ERROR: unable to analyze dump EMCheckCompatibility True Adapter Vendor ID 0x10de Adapter Device ID 0x 869 Frame Module Signature Source 0 libRIP.A.dylib ripc_GetColor 1 libRIP.A.dylib ripc_Render 2 libRIP.A.dylib ripc_DrawRects 3 CoreGraphics CGContextFillRects 4 CoreGraphics CGContextFillRect 5 AppKit NSRectFillUsingOperation 6 AppKit -[NSGrayFrame drawWindowBackgroundRect:] 7 AppKit -[NSFrameView drawThemeContentFill:inView:] 8 AppKit -[NSGrayFrame drawRect:] 9 AppKit -[NSView _drawRect:clip:] 10 AppKit -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] 11 AppKit -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibl 12 AppKit -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIs 13 AppKit -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] 14 AppKit -[NSView displayIfNeeded] 15 AppKit -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] 16 AppKit -[NSWindow orderWindow:relativeTo:] 17 AppKit -[NSWindow makeKeyAndOrderFront:] 18 XUL nsCocoaWindow::Show widget/cocoa/nsCocoaWindow.mm:774 19 XUL nsXULWindow::SetVisibility xpfe/appshell/src/nsXULWindow.cpp:803 20 XUL nsXULWindow::OnChromeLoaded xpfe/appshell/src/nsXULWindow.cpp:1000 21 XUL nsWebShellWindow::OnStateChange xpfe/appshell/src/nsWebShellWindow.cpp:563 22 XUL _ZThn224_N16nsWebShellWindow13OnStateChangeEP14nsIWebProgressP10nsIRequestj12tag xpfe/appshell/src/nsWebShellWindow.cpp:567 23 XUL nsDocLoader::DoFireOnStateChange uriloader/base/nsDocLoader.cpp:1305 24 XUL nsDocLoader::doStopDocumentLoad uriloader/base/nsDocLoader.cpp:896 25 XUL nsDocLoader::DocLoaderIsEmpty uriloader/base/nsDocLoader.cpp:775 26 XUL nsDocLoader::OnStopRequest uriloader/base/nsDocLoader.cpp:659 27 XUL _ZThn8_N11nsDocLoader13OnStopRequestEP10nsIRequestP11nsISupports12tag_nsresult uriloader/base/nsDocLoader.cpp:663 28 XUL nsLoadGroup::RemoveRequest netwerk/base/src/nsLoadGroup.cpp:697 29 XUL nsDocument::DoUnblockOnload content/base/src/nsDocument.cpp:6992 30 XUL nsUnblockOnloadEvent::Run content/base/src/nsDocument.cpp:6945 31 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:627 32 XUL NS_ProcessPendingEvents_P obj-firefox/x86_64/xpcom/build/nsThreadUtils.cpp:188 33 XUL nsBaseAppShell::NativeEventCallback widget/xpwidgets/nsBaseAppShell.cpp:97 34 XUL nsAppShell::ProcessGeckoEvents widget/cocoa/nsAppShell.mm:387 35 CoreFoundation __CFRunLoopDoSources0 36 CoreFoundation __CFRunLoopRun 37 CoreFoundation CFRunLoopRunSpecific 38 HIToolbox HIToolbox@0x2e7ee 39 HIToolbox HIToolbox@0x2e551 40 HIToolbox HIToolbox@0x2e4ac 41 AppKit _DPSNextEvent 42 AppKit -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 43 XUL -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] widget/cocoa/nsAppShell.mm:164 44 AppKit -[NSApplication run] 45 XUL nsAppShell::Run widget/cocoa/nsAppShell.mm:741 46 XUL nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:290 47 XUL XREMain::XRE_mainRun toolkit/xre/nsAppRunner.cpp:3823 48 XUL XREMain::XRE_main toolkit/xre/nsAppRunner.cpp:3890 49 XUL XRE_main toolkit/xre/nsAppRunner.cpp:4084 50 firefox main browser/app/nsBrowserApp.cpp:174 51 firefox start More reports at: https://crash-stats.mozilla.com/report/list?signature=ripc_GetColor
I found one of these in FF 3.0.19 (bp-b61054f7-aa97-4fee-b7c4-a49632130129). So they've been around for a while. But their frequency does seem to have increased recently, starting in the 20130109111322 build. This might be an OS bug (or possibly more than one). I see a bunch on OS X 10.6.X (plus a few on 10.5.X), and a bunch on 10.8.X, but none on 10.7.X. https://crash-stats.mozilla.com/report/list?product=Firefox&platform=mac&query_search=signature&query_type=contains&query=ripc_&reason_type=contains&date=02%2F09%2F2013%2018%3A05%3A11&range_value=4&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=ripc_GetColor
This bug is so nebulous that we probably can't do anything about it until we can reliably reproduce it.
The following three crash reports, picked more or less at random, seem to be using the System Theme (extension 972ce4c6-7e08-4474-a285-3208198ce6fd). So I'll bet themes don't come into this bug. bp-c2417624-5c03-48b8-a73e-401b22130208 bp-c4885c72-2b35-4c56-944f-ebdc72130123 bp-756e74a0-9947-4c05-b0b7-84d032130208 URLs might, though.
Crash Signature: [@ ripc_GetColor] → [@ ripc_GetColor ]
But the last URL points to someone possibly using Anchor Free - http://www.anchorfree.com/. (In reply to Marcia Knous [:marcia] from comment #6) > Not many URLs show up: > > 24 about:blank > 1 wyciwyg://22011/http://ads.bibme.org/iframe_leaderboard.html > 1 http://rss2search.com/novus/?sec=ent&from=pop
Thanks for the info, Marcia. I'd hoped that this bug might only be happening to people who'd changed their home pages (away from about:blank). Apparently not.
Socorro has only one of these in the last 4 weeks (in FF 20): https://crash-stats.mozilla.com/report/list?signature=ripc_GetColor&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&platform=mac&hang_type=any&date=2013-12-16+20%3A00%3A00&range_value=4#reports I don't know what "fixed" this, but I think we can say it's gone.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
I just remembered that we no longer report non-Mozilla symbols in our stack reports. But I can't find any of these as libRIP.dylib@0xNNNN signatures, either.
(In reply to Steven Michaud from comment #10) > I just remembered that we no longer report non-Mozilla symbols in our stack > reports. That sounds like a bug, e.g. that we didn't push symbols to our servers, is it filed?
> That sounds like a bug I'm sure it is. It's been true for months (at least). Hadn't you noticed it? > is it filed? Probably. Let me see if I can find it.
> Let me see if I can find it. I couldn't, so I opened bug 951229.
(In reply to Steven Michaud from comment #13) > I couldn't, so I opened bug 951229. Thanks, let's follow up there.
You need to log in before you can comment on or make changes to this bug.