[Webkit-unassigned] [Bug 197266] New: [WPE][GTK] Crash when Connection is destroyed when Connection::invalidate is destroyed

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=197266

            Bug ID: 197266
           Summary: [WPE][GTK] Crash when Connection is destroyed when
                    Connection::invalidate is destroyed
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at igalia.com
                CC: bugs-noreply at webkitgtk.org

Created attachment 368205

  --> https://bugs.webkit.org/attachment.cgi?id=368205&action=review

Full backtrace

I've been hitting this non-reproducible crash somewhat regularly when closing MiniBrowser for a few months now, but never figured out what's going wrong and never bothered to report it until now. The backtrace is really hard to read due to inlining, and I just don't see what's happening.

The crash occurs here in Connection::invalidate:

    m_connectionQueue->dispatch([protectedThis = makeRef(*this)]() mutable {
        protectedThis->platformInvalidate();
    });

But it's hard to see what's going on. The lambda executes, then lambda is destroyed, and so protectedThis (the Ref<Connection>) is destroyed... presumably the refcount drops to 0 for some reason (no clue why -- doesn't look like Connection::platformInvalidate is doing anything that could cause this -- but anyway it's clearly expected as that's why there's the protector), then ~Connection destructor is called... and something goes wrong, it's really not clear what from the backtrace. I had been thinking the crash occurs when destroying m_incomingMessagesThrottler, which is a std::unique_ptr<MessagesThrottler>. The MessagesThrottler class contains a RunLoop::Timer<Connection>, and RunLoopGLib.cpp is the only place in WebKit where we directly call g_source_set_ready_time(), so that looked suspicious. But there's no way the ~Timer or ~TimerBase destructors should be calling g_source_set_ready_time(). They only call g_source_destroy(). Doesn't make sense to me.

Anyway:

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 g_source_set_ready_time at ../glib/gmain.c:1857
 #1 WTF::ThreadSafeRefCounted<IPC::Connection, (WTF::DestructionThread)1>::deref at /usr/include/c++/9/bits/unique_ptr.h:283
 #3 WTF::Ref<IPC::Connection, WTF::DumbPtrTraits<IPC::Connection> >::~Ref at DerivedSources/ForwardingHeaders/wtf/Ref.h:60
 #4 IPC::Connection::<lambda()>::~<lambda> at ../Source/WebKit/Platform/IPC/Connection.cpp:385
 #5 WTF::Function<void()>::CallableWrapper<IPC::Connection::invalidate()::<lambda()> >::~CallableWrapper at DerivedSources/ForwardingHeaders/wtf/Function.h:92
 #6 WTF::Function<void()>::CallableWrapper<IPC::Connection::invalidate()::<lambda()> >::~CallableWrapper(void) at DerivedSources/ForwardingHeaders/wtf/Function.h:92
 #7 std::default_delete<WTF::Function<void ()>::CallableWrapperBase>::operator()(WTF::Function<void ()>::CallableWrapperBase*) const at /usr/include/c++/9/bits/unique_ptr.h:75
 #8 std::unique_ptr<WTF::Function<void ()>::CallableWrapperBase, std::default_delete<WTF::Function<void ()>::CallableWrapperBase> >::~unique_ptr() at /usr/include/c++/9/bits/unique_ptr.h:289
 #9 WTF::Function<void ()>::~Function() at ../Source/WTF/wtf/Function.h:36
 #10 WTF::WorkQueue::<lambda()>::~<lambda> at ../Source/WTF/wtf/generic/WorkQueueGeneric.cpp:62

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190425/6ff6d796/attachment.html>