While investigating a crash in the 'create-lots-of-workers' test (see https://bugs.webkit.org/show_bug.cgi?id=115130), I found that there were a number of cases where objects were created using the system allocator, but later freed using the 'fastFree' overload provided by fastMalloc.h.
I proposed having Windows build using the same settings as Gtk/EFL/QT, which is to avoid overloading global operator new/delete with the fastMalloc varients (which fixes the crash). However, I was not sure if this would create any kind of performance regression. Oliver Hunt suggested I document which objects were falling into this mismatched allocator/deallocator camp. I used a tool called BoundsChecker (similar to Valgrind) to see if I could identify which objects fell into this category: Allocator mismatches (running DumpRenderTree on create-lots-of-workers): 1. DumpRenderTree.cpp, Line 245: [...] if (lastSlash != -1 && lastSlash + 1 < path.length()) path = path.substr(0, lastSlash + 1); return path; Here, path is set to the result of the substr method, which internally uses the system 'new'. When this temporary is destroyed on return, it is passing through fastFree. 2. DumpRenderTree.cpp, Line 307 (addQTDirToPATH): // And add the QuickTime dll. wstring newPath; newPath.append(qtPath); newPath.append(L";"); newPath.append(oldPath.data(), oldPath.size()); SetEnvironmentVariableW(pathEnvironmentVariable, newPath.data()); The various calls to 'append' internally use the system 'new'. When the newPath temporary is destroyed on method exit, it is cleaned up by fastFree. 3. CSSParser.cpp, Line 421 (setupParser): if (!stringLength || string.is8Bit()) { m_dataStart8 = adoptArrayPtr(new LChar[length]); The m_dataStart8 array is supposedly allocated using system new. In the destructor, fastFree is getting called. 3. SelectorFilter.cpp, Line 89 (setupParentStack): m_parentStack.shrink(0); m_ancestorIdentifierFilter = adoptPtr(new BloomFilter<bloomFilterKeyBits>); The m_ancestorIdentifierFilter BloomFilter is allocated using system new, but destroyed (later, in SelectorFilter::popParentStackFrame) by fastFree. 4. WebKitSystemInterface.cpp, Line 724 (wkCACFContextCreate): Create of the context object is allocated with system new. Later, wkCACFContextDestroy calls fastFree to cleanup. 5. PluginPackageWin.cpp, Line 174 (fetchInfo): OwnArrayPtr<char> versionInfoData = adoptArrayPtr(new char[versionInfoSize]); A character array is allocated using system new, and is cleaned up at scope exit by fastFree. 4. ThreadingWin.cpp, Line 230 (createThreadInternal): OwnPtr<ThreadFunctionInvocation> invocation = adoptPtr(new ThreadFunctionInvocation(entryPoint, data)); ThreadFunctionInvocation is allocated with system new, but deleted by fastFree. Not all of these cases make sense to me, so BoundsChecker may be reporting some false positives. For example, I don't see how the 'ThreadingWin.cpp' case would simultaneously see system 'new' for the adoptPtr call, but then call 'fastFree' when cleaning up. The entire object's life-cycle is in a few lines of code. Thanks, -Brent
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev