Bug 118939 – Updated ANGLE is leaking like a sieve

• Status: RESOLVED
• Resolution: FIXED
• Component: WebGL

[Mark Rowe (bdash)]

"run-webkit-tests --leaks" on OS X results in 4.5GB of leaks output. Buildbot chokes on handling this much data, which is why build.webkit.org has been so flakey the last few days.

An example of the leaks output is:

        Call stack: [thread 0x7fff783d4310]: | 0x2 | start | main DumpRenderTree.mm:953 | dumpRenderTree(int, char const**) DumpRenderTree.mm:915 | runTestingServerLoop() DumpRenderTree.mm:860 | runTest(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) DumpRenderTree.mm:1408 | -[NSRunLoop(NSRunLoop) runMode:beforeDate:] | CFRunLoopRunSpecific | __CFRunLoopRun | __CFRunLoopDoSources0 | __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ | MultiplexerSource::_perform(void*) | MultiplexerSource::perform() | RunloopBlockContext::perform() | CFArrayApplyFunction | ___ZNK17CoreSchedulingSet13_performAsyncEPKcU13block_pointerFvvE_block_invoke | ___ZN27URLConnectionClient_Classic18_withDelegateAsyncEPKcU13block_pointerFvP16_CFURLConnectionPK33CFURLConnectionClientCurrent_VMaxE_block_invoke_2 | ___ZN27URLConnectionClient_Classic29_delegate_didReceiveDataArrayEv_block_invoke | _NSURLConnectionDidReceiveData_LengthReceived | -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] | -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] | __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke | -[WebCoreResourceHandleAsDelegate connection:didReceiveData:lengthReceived:] WebCoreResourceHandleAsDelegate.mm:195 | WebCore::ResourceLoader::didReceiveBuffer(WebCore::ResourceHandle*, WTF::PassRefPtr<WebCore::SharedBuffer>, int) ResourceLoader.cpp:482 | WebCore::SubresourceLoader::didReceiveBuffer(WTF::PassRefPtr<WebCore::SharedBuffer>, long long, WebCore::DataPayloadType) SubresourceLoader.cpp:231 | WebCore::SubresourceLoader::didReceiveDataOrBuffer(char const*, int, WTF::PassRefPtr<WebCore::SharedBuffer>, long long, WebCore::DataPayloadType) SubresourceLoader.cpp:250 | WebCore::CachedRawResource::addDataBuffer(WebCore::ResourceBuffer*) CachedRawResource.cpp:67 | WebCore::CachedRawResource::notifyClientsDataWasReceived(char const*, unsigned int) CachedRawResource.cpp:110 | WebCore::DocumentLoader::dataReceived(WebCore::CachedResource*, char const*, int) DocumentLoader.cpp:848 | WebCore::DocumentLoader::commitLoad(char const*, int) DocumentLoader.cpp:740 | WebFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, char const*, int) WebFrameLoaderClient.mm:890 | -[WebDataSource(WebInternal) _receivedData:] WebDataSource.mm:215 | -[WebHTMLRepresentation receivedData:withDataSource:] WebHTMLRepresentation.mm:189 | -[WebFrame(WebInternal) _commitData:] WebFrame.mm:838 | WebCore::DocumentLoader::commitData(char const*, unsigned long) DocumentLoader.cpp:798 | WebCore::DocumentWriter::addData(char const*, unsigned long) DocumentWriter.cpp:226 | WebCore::DecodedDataDocumentParser::appendBytes(WebCore::DocumentWriter*, char const*, unsigned long) DecodedDataDocumentParser.cpp:50 | WebCore::HTMLDocumentParser::append(WTF::PassRefPtr<WTF::StringImpl>) HTMLDocumentParser.cpp:742 | WebCore::HTMLDocumentParser::pumpTokenizerIfPossible(WebCore::HTMLDocumentParser::SynchronousMode) HTMLDocumentParser.cpp:235 | WebCore::HTMLDocumentParser::pumpTokenizer(WebCore::HTMLDocumentParser::SynchronousMode) HTMLDocumentParser.cpp:535 | WebCore::HTMLDocumentParser::canTakeNextToken(WebCore::HTMLDocumentParser::SynchronousMode, WebCore::PumpSession&) HTMLDocumentParser.cpp:291 | WebCore::HTMLDocumentParser::runScriptsForPausedTreeBuilder() HTMLDocumentParser.cpp:271 | WebCore::HTMLScriptRunner::execute(WTF::PassRefPtr<WebCore::Element>, WTF::TextPosition const&) HTMLScriptRunner.cpp:183 | WebCore::HTMLScriptRunner::runScript(WebCore::Element*, WTF::TextPosition const&) HTMLScriptRunner.cpp:314 | WebCore::ScriptElement::prepareScript(WTF::TextPosition const&, WebCore::ScriptElement::LegacyTypeSupport) ScriptElement.cpp:245 | WebCore::ScriptElement::executeScript(WebCore::ScriptSourceCode const&) ScriptElement.cpp:316 | WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const&) ScriptController.cpp:158 | WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const&, WebCore::DOMWrapperWorld*) ScriptController.cpp:142 | WebCore::JSMainThreadExecState::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) JSMainThreadExecState.h:77 | JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) Completion.cpp:83 | JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::JSObject*) Interpreter.cpp:951 | JSC::JITCode::execute(JSC::JSStack*, JSC::ExecState*, JSC::VM*) JITCode.h:135 | 0x307901201045 | WebCore::jsWebGLRenderingContextPrototypeFunctionCompileShader(JSC::ExecState*) JSWebGLRenderingContext.cpp:1503 | WebCore::WebGLRenderingContext::compileShader(WebCore::WebGLShader*, int&) WebGLRenderingContext.cpp:1303 | WebCore::GraphicsContext3D::compileShader(unsigned int) GraphicsContext3DOpenGLCommon.cpp:447 | WebCore::Extensions3DOpenGLCommon::getTranslatedShaderSourceANGLE(unsigned int) Extensions3DOpenGLCommon.cpp:179 | WebCore::ANGLEWebKitBridge::compileShaderSource(char const*, WebCore::ANGLEShaderType, WTF::String&, WTF::String&, WTF::Vector<WebCore::ANGLEShaderSymbol, 0ul, WTF::CrashOnOverflow>&, int) ANGLEWebKitBridge.cpp:173 | ShConstructCompiler ShaderLang.cpp:156 | TCompiler::Init(ShBuiltInResources const&) Compiler.cpp:148 | TCompiler::InitBuiltInSymbolTable(ShBuiltInResources const&) Compiler.cpp:276 | (anonymous namespace)::InitializeSymbolTable(TVector<std::__1::basic_string<char, std::__1::char_traits<char>, pool_allocator<char> > > const&, ShShaderType, ShShaderSpec, ShBuiltInResources const&, TInfoSink&, TSymbolTable&) Compiler.cpp:76 | InsertBuiltInFunctionsCommon(ShBuiltInResources const&, TSymbolTable*) builtin_symbol_table.cpp:86 | builtin1(TSymbolTable*, TType*, char const*, TType*, char const*) builtin_symbol_table.cpp:15 | operator new(unsigned long) | malloc | malloc_zone_malloc 

Almost all of the leaks I've looked at have had the same stack trace.

[Mark Rowe (bdash)]

For reference, ANGLE was updated in r152755. I'm a little bit confused by the fact that mentions updating to ANGLE r2426, but ANGLE appears to have switched to Git at some point during June. I can't find any revision of their master branch that corresponds to a r2426.

[Radar WebKit Bug Importer]

<rdar://problem/14501257>

[Dean Jackson]

Created attachment 207202 [details]
Patch

[Tobias Netzel]

It seems the version number may come from the latest subversion revision number, which was 2426:
http://angleproject.googlecode.com/svn/

Confusing is the fact that in the git repository
http://code.google.com/p/angleproject/source/browse/src/common/version.h
currently lists a build revision of 2426, with angle version 1.2.0 while the latest svn trunk
http://angleproject.googlecode.com/svn/trunk/src/common/version.h
lists a build revision of 2249, with angle version 1.0.0 .

Possibly the svn revision of 2426 was confused with the build revision of 2426, while the intention might have been to get the current build revision of 2426.

[Alex Christensen]

I did update to the latest svn revision, and they did switch over to git, so any further updates will need to be from the git repository.

This is probably not from the update, but rather from r152746 where I unskipped the webgl tests.  Maybe we should just reskip them to speed up the buildbots until this is fixed?

[Alex Christensen]

> This is probably not from the update, but rather from r152746 where I unskipped the webgl tests.  Maybe we should just reskip them to speed up the buildbots until this is fixed?

Never mind.  Rolling out the update and keeping the changes seems to have fixed the leaks.

[Tobias Netzel]

But the update seems somehow incomplete; at least version.h wasn't updated (see http://trac.webkit.org/log/trunk/Source/ThirdParty/ANGLE/src/common/version.h).

[Alex Christensen]

(In reply to comment #7)
> But the update seems somehow incomplete; at least version.h wasn't updated (see http://trac.webkit.org/log/trunk/Source/ThirdParty/ANGLE/src/common/version.h).

Yes, I was trying to stick with their svn repository, which is what we had done in the past, but they've stopped updating and maintaining their svn repository.  I'm going to switch to using their git repository and make sure they fixed the leaks we were seeing.

[Alex Christensen]

The ANGLE update that caused this was rolled out in r152946 and the correct update was done in r153064.