⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.

Changeset 270496 in webkit


Ignore:
Timestamp:
Dec 7, 2020, 1:19:31 AM (6 years ago)
Author:
commit-queue@webkit.org
Message:

[GLib] Leaked RunLoop objects on worker threads
​https://bugs.webkit.org/show_bug.cgi?id=219232
<rdar://problem/71772277>

Patch by Zan Dobersek <​zdobersek@igalia.com> on 2020-12-07
Reviewed by Geoffrey Garen.

Source/WTF:

During the thread-local RunLoop::Holder destruction, explicitly clear out
the iteration Deque objects on the held RunLoop, destroying any Function
objects that never got to execute on this thread. Generally, this allows
for any RunLoop reference stored in these objects to be released.

Specifically, this would allow for destruction of the RunLoop::Timer
object that's queued up in the JSRunLoopTimer::Manager::PerVMData
destructor but never gets dispatched because the thread (a JS worker) is
shut down before that happens. Destruction of the timer will release the
reference of the RunLoop that's held by the RunLoop::Holder, finally
enabling the RunLoop object itself be destroyed once the RunLoop::Holder
reference is let go.

  • wtf/RunLoop.cpp:

(WTF::RunLoop::Holder::~Holder):
(WTF::RunLoop::threadWillExit):

  • wtf/RunLoop.h:

Tools:

Add a unit test covering proper RunLoop teardown upon thread destruction
even if RunLoop references are stored in the dispatch queues.

  • TestWebKitAPI/Tests/WTF/RunLoop.cpp:

(TestWebKitAPI::TEST):

Location:
trunk
Files:
5 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/WTF/ChangeLog

    r270488 r270496  
     12020-12-07  Zan Dobersek  <zdobersek@igalia.com>
     2
     3        [GLib] Leaked RunLoop objects on worker threads
     4        https://bugs.webkit.org/show_bug.cgi?id=219232
     5        <rdar://problem/71772277>
     6
     7        Reviewed by Geoffrey Garen.
     8
     9        During the thread-local RunLoop::Holder destruction, explicitly clear out
     10        the iteration Deque objects on the held RunLoop, destroying any Function
     11        objects that never got to execute on this thread. Generally, this allows
     12        for any RunLoop reference stored in these objects to be released.
     13
     14        Specifically, this would allow for destruction of the RunLoop::Timer
     15        object that's queued up in the JSRunLoopTimer::Manager::PerVMData
     16        destructor but never gets dispatched because the thread (a JS worker) is
     17        shut down before that happens. Destruction of the timer will release the
     18        reference of the RunLoop that's held by the RunLoop::Holder, finally
     19        enabling the RunLoop object itself be destroyed once the RunLoop::Holder
     20        reference is let go.
     21
     22        * wtf/RunLoop.cpp:
     23        (WTF::RunLoop::Holder::~Holder):
     24        (WTF::RunLoop::threadWillExit):
     25        * wtf/RunLoop.h:
     26
    1272020-12-06  Samuel Thibault  <samuel.thibault@ens-lyon.org>
    228
  • trunk/Source/WTF/wtf/RunLoop.cpp

    r265735 r270496  
    4545        : m_runLoop(adoptRef(*new RunLoop))
    4646    {
     47    }
     48
     49    ~Holder()
     50    {
     51        m_runLoop->threadWillExit();
    4752    }
    4853
    … …  
    167172}
    168173
     174void RunLoop::threadWillExit()
     175{
     176    m_currentIteration.clear();
     177    m_nextIteration.clear();
     178}
     179
    169180} // namespace WTF
  • trunk/Source/WTF/wtf/RunLoop.h

    r270311 r270496  
    9898    WTF_EXPORT_PRIVATE CycleResult static cycle(RunLoopMode = DefaultRunLoopMode);
    9999
     100    WTF_EXPORT_PRIVATE void threadWillExit();
     101
    100102#if USE(GLIB_EVENT_LOOP)
    101103    WTF_EXPORT_PRIVATE GMainContext* mainContext() const { return m_mainContext.get(); }
  • trunk/Tools/ChangeLog

    r270478 r270496  
     12020-12-07  Zan Dobersek  <zdobersek@igalia.com>
     2
     3        [GLib] Leaked RunLoop objects on worker threads
     4        https://bugs.webkit.org/show_bug.cgi?id=219232
     5        <rdar://problem/71772277>
     6
     7        Reviewed by Geoffrey Garen.
     8
     9        Add a unit test covering proper RunLoop teardown upon thread destruction
     10        even if RunLoop references are stored in the dispatch queues.
     11
     12        * TestWebKitAPI/Tests/WTF/RunLoop.cpp:
     13        (TestWebKitAPI::TEST):
     14
    1152020-12-04  Wenson Hsieh  <wenson_hsieh@apple.com>
    216
  • trunk/Tools/TestWebKitAPI/Tests/WTF/RunLoop.cpp

    r264017 r270496  
    216216}
    217217
     218TEST(WTF_RunLoop, ThreadTerminationSelfReferenceCleanup)
     219{
     220    RefPtr<RunLoop> runLoop;
     221
     222    Thread::create("RunLoopThreadTerminationSelfReferenceCleanup", [&] {
     223        runLoop = makeRefPtr(RunLoop::current());
     224
     225        // This stores a RunLoop reference in the dispatch queue that will not be released
     226        // via the usual dispatch, but should still be released upon thread termination.
     227        // After that, the observing RefPtr should be the only one holding a reference
     228        // to the RunLoop object.
     229        runLoop->dispatch([ref = runLoop.copyRef()] { });
     230    })->waitForCompletion();
     231
     232    EXPECT_TRUE(runLoop->hasOneRef());
     233}
     234
    218235} // namespace TestWebKitAPI
Note: See TracChangeset for help on using the changeset viewer.