2010-09-02 Alexey Proskuryakov <ap@apple.com>
authorap@apple.com <ap@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 2 Sep 2010 12:57:58 +0000 (12:57 +0000)
committerap@apple.com <ap@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 2 Sep 2010 12:57:58 +0000 (12:57 +0000)
commit81eeef1468c5f4c721f083a8b82674d02f357e79
treec635854b5e5a4579f43dddf13f1d478bb2c42855
parent0def2a7f35b5373bfab8b76af376cd3aa56d37ff
2010-09-02  Alexey Proskuryakov  <ap@apple.com>

        Reviewed by Oliver Hunt.

        https://bugs.webkit.org/show_bug.cgi?id=43230
        <rdar://problem/8254215> REGRESSION: Memory leak within JSParser::JSParser

        One can't delete a ThreadSpecific object that has data in it. It's not even possible to
        enumerate data objects in all threads, much less destroy them from a thread that's destroying
        the ThreadSpecific.

        * parser/JSParser.cpp:
        (JSC::JSParser::JSParser):
        * runtime/JSGlobalData.h:
        * wtf/WTFThreadData.cpp:
        (WTF::WTFThreadData::WTFThreadData):
        * wtf/WTFThreadData.h:
        (WTF::WTFThreadData::approximatedStackStart):
        Moved stack guard tracking from JSGlobalData to WTFThreadData.

        * wtf/ThreadSpecific.h: Made destructor unimplemented. It's dangerous, and we probably won't
        ever face a situation where we'd want to delete a ThreadSpecific object.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@66665 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JavaScriptCore/ChangeLog
JavaScriptCore/parser/JSParser.cpp
JavaScriptCore/runtime/JSGlobalData.h
JavaScriptCore/wtf/ThreadSpecific.h
JavaScriptCore/wtf/WTFThreadData.cpp
JavaScriptCore/wtf/WTFThreadData.h