Bug 165655
| Summary: | [SOUP] Network process crash in WebKit::CustomProtocolManagerImpl::start | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | bugs-noreply, cgarcia, mcatanzaro, zan |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: | https://bugzilla.redhat.com/show_bug.cgi?id=1403138 | ||
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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 ***