The OS X leaks tool tells me that we're leaking a shader here: Call stack: [thread 0x7fff7110eca0]: | start | main | XRE_main | nsAppStartup::Run() | nsAppShell::Run() | -[NSApplication run] | -[NSApplication nextEventMatchin gMask:untilDate:inMode:dequeue:] | _DPSNextEvent | BlockUntilNextEventMatchingListInMode | ReceiveNextEventCommon | RunCurrentEventLoopInMode | CFRunLoopRunSpecific | __C FRunLoopRun | __CFRunLoopDoSources0 | nsAppShell::ProcessGeckoEvents(void*) | nsBaseAppShell::NativeEventCallback() | NS_ProcessPendingEvents_P(nsIThread*, unsigned int) | nsThread::ProcessNextEvent(int, int*) | nsRunnableMethodImpl<void (nsDocument::*)(), true>::Run() | nsDocument::DispatchContentLoadedEvents() | nsDocument::DoUnblockOnl oad() | nsLoadGroup::RemoveRequest(nsIRequest*, nsISupports*, unsigned int) | nsDocLoader::OnStopRequest(nsIRequest*, nsISupports*, unsigned int) | nsDocLoader::DocLoader IsEmpty(int) | nsDocLoader::DocLoaderIsEmpty(int) | nsDocLoader::FireOnStateChange(nsIWebProgress*, nsIRequest*, int, unsigned int) | nsWebShellWindow::OnStateChange(nsIW ebProgress*, nsIRequest*, unsigned int, unsigned int) | nsXULWindow::OnChromeLoaded() | nsXULWindow::SetVisibility(int) | nsCocoaWindow::Show(int) | -[NSWindow makeKeyAnd OrderFront:] | -[NSWindow orderWindow:relativeTo:] | -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] | -[NSView displayIfNeeded] | -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] | -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView: topView:] | -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] | -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRe ct:] | -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] | -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] | -[NSView _drawRect:clip:] | -[ChildView dra wRect:] | -[ChildView drawRect:inContext:] | nsBaseWidget::GetLayerManager(nsIWidget_MOZILLA_2_0_BRANCH::LayerManagerPersistence, bool*) | mozilla::layers::LayerManagerOG L::Initialize(nsRefPtr<mozilla::gl::GLContext>) | mozilla::layers::ColorTextureLayerProgram::Initialize(char const*, char const*) | mozilla::layers::LayerManagerOGLProgra m::CreateProgram(char const*, char const*) | glCompileShaderARB_Exec | gleShaderParse | ShCompile | generateBuiltInSymbolTable(glslResources const*, TInfoSink&, TSymbolTa ble*, EShLanguage) | initializeSymbolTable(TBuiltIns&, EShLanguage, TInfoSink&, glslResources const*, TSymbolTable*) | operator new(unsigned long) | malloc | malloc_zone_ malloc· Looking at the code, I think I believe it. We're just bailing out if any of the two shaders have not been created successfully, which makes me think that the theory that I put in the summary field happens in practice. I'd write a patch, but I don't know what's the correct way to free this shader.

I'm downgrading to a MemShrink:P3 because the leak only happens in the error (shader failed to create) case.