Open Bug 644073 Opened 9 years ago Updated Last year

LayerManagerOGLProgram::CreateProgram leaks the vertex shader if creating the fragment shader fails


(Core :: Graphics, defect)

Not set




(Reporter: ehsan, Unassigned)




(Whiteboard: [MemShrink:P3])

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_

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.
Whiteboard: [MemShrink:P2]
I'm downgrading to a MemShrink:P3 because the leak only happens in the error (shader failed to create) case.
Whiteboard: [MemShrink:P2] → [MemShrink:P3]
You need to log in before you can comment on or make changes to this bug.