[webkit-dev] Mismatched Allocators in Windows

[Brent Fulgham]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130501/e4abc9e3/attachment.html>