Bug 165655 – [SOUP] Network process crash in WebKit::CustomProtocolManagerImpl::start

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebKitGTK

[Michael Catanzaro]

We seem to have a lot of SOUP crashes in WebKit::CustomProtocolManagerImpl (e.g. bug #149565, bug #165082). Here's one more:

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 g_type_check_instance_cast at gtype.c:4051
 #1 WebKit::WebSoupRequestAsyncData::~WebSoupRequestAsyncData at /usr/src/debug/webkitgtk-2.14.2/Source/WebKit2/NetworkProcess/CustomProtocols/soup/CustomProtocolManagerImpl.cpp:55
 #2 std::default_delete<WebKit::WebSoupRequestAsyncData>::operator() at /usr/include/c++/6.2.1/bits/unique_ptr.h:76
 #3 std::unique_ptr<WebKit::WebSoupRequestAsyncData, std::default_delete<WebKit::WebSoupRequestAsyncData> >::reset at /usr/include/c++/6.2.1/bits/unique_ptr.h:344
 #4 std::unique_ptr<WebKit::WebSoupRequestAsyncData, std::default_delete<WebKit::WebSoupRequestAsyncData> >::operator=(std::unique_ptr<WebKit::WebSoupRequestAsyncData, std::default_delete<WebKit::WebSoupRequestAsyncData> >&&) at /usr/include/c++/6.2.1/bits/unique_ptr.h:251
 #5 WTF::HashMap<unsigned long, std::unique_ptr<WebKit::WebSoupRequestAsyncData, std::default_delete<WebKit::WebSoupRequestAsyncData> >, WTF::IntHash<unsigned long>, WTF::HashTraits<unsigned long>, WTF::HashTraits<std::unique_ptr<WebKit::WebSoupRequestAsyncData, std::default_delete<WebKit::WebSoupRequestAsyncData> > > >::inlineSet<unsigned long const&, std::unique_ptr<WebKit::WebSoupRequestAsyncData, std::default_delete<WebKit::WebSoupRequestAsyncData> > >(unsigned long const&, std::unique_ptr<WebKit::WebSoupRequestAsyncData, std::default_delete<WebKit::WebSoupRequestAsyncData> >&&) at /usr/src/debug/webkitgtk-2.14.2/Source/WTF/wtf/HashMap.h:308
 #6 WTF::HashMap<unsigned long, std::unique_ptr<WebKit::WebSoupRequestAsyncData, std::default_delete<WebKit::WebSoupRequestAsyncData> >, WTF::IntHash<unsigned long>, WTF::HashTraits<unsigned long>, WTF::HashTraits<std::unique_ptr<WebKit::WebSoupRequestAsyncData, std::default_delete<WebKit::WebSoupRequestAsyncData> > > >::set<std::unique_ptr<WebKit::WebSoupRequestAsyncData, std::default_delete<WebKit::WebSoupRequestAsyncData> > >(unsigned long const&, std::unique_ptr<WebKit::WebSoupRequestAsyncData, std::default_delete<WebKit::WebSoupRequestAsyncData> >&&) at /usr/src/debug/webkitgtk-2.14.2/Source/WTF/wtf/HashMap.h:331
 #7 WebKit::CustomProtocolManagerImpl::start at /usr/src/debug/webkitgtk-2.14.2/Source/WebKit2/NetworkProcess/CustomProtocols/soup/CustomProtocolManagerImpl.cpp:201
 #8 WebCore::ResourceHandle::start at /usr/src/debug/webkitgtk-2.14.2/Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp:1032
 #9 WebCore::ResourceHandle::create at /usr/src/debug/webkitgtk-2.14.2/Source/WebCore/platform/network/ResourceHandle.cpp:101

The user reports "just after logging into computer the alert popped up saying that an error occurred." Full backtrace downstream.

[Carlos Garcia Campos]

This is pretty weird... The crash happens in:

m_customProtocolMap.set(customProtocolID, std::make_unique<WebSoupRequestAsyncData>(task, request));

And the bt says that there's already an entry in the map for the customProtocolID (68). That's not expected to happen, since that value comes from:

uint64_t customProtocolID = generateCustomProtocolID();

So, what happens is that the current value for that customProtocolID is deleted and in ~WebSoupRequestAsyncData() request is non-null but it's not a GObject either, so g_object_remove_weak_pointer fails.

This is probably due to a memory corruption or something. Do you know how to reproduce the crash?

[Michael Catanzaro]

(In reply to comment #1)
> Do you know how to reproduce the crash?

Nope.

FYI: this particular crash has only two reports total in Fedora, so maybe not a priority. The similar crash bug #149565 has 157 reports, but none since 2.10.4, so I've closed it just now. The also-similar bug #165082 has 850 reports still rolling in, most recently on Saturday.

[Michael Catanzaro]

Let's assume this is related to bug #165082.

*** This bug has been marked as a duplicate of bug 165082 ***