Bug 195532

Summary: [GTK] webkit2gtk3: magazine_chain_pop_head(): WebKitWebProcess killed by SIGSEGV
Product: WebKit Reporter: Ryan Farmer <rfarmer84>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: bugs-noreply, mcatanzaro
Priority: P2    
Version: WebKit Nightly Build   
Hardware: PC   
OS: Linux   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=1687186
Attachments:
Description Flags
backtrace
none
cgroup
none
core backtrace
none
cpu info
none
dso list
none
environ
none
exploitable
none
limits
none
maps
none
mountinfo
none
open fds
none
proc pid status none

Description Ryan Farmer 2019-03-10 11:53:58 PDT
Created attachment 364183 [details]
backtrace

This is a copy of this bug on fedora's Bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=1687186

Description of problem:
Watching the video about GTA V on this page causes the webkit process to crash.

https://laptoping.com/gpus/product/intel-hd-620-review-graphics-of-7th-gen-core-u-series-kaby-lake-cpus/

Version-Release number of selected component:
webkit2gtk3-2.22.7-1.fc29

Additional info:
reporter:       libreport-2.10.0
backtrace_rating: 4
cmdline:        /usr/libexec/webkit2gtk-4.0/WebKitWebProcess 7 48
crash_function: magazine_chain_pop_head
executable:     /usr/libexec/webkit2gtk-4.0/WebKitWebProcess
journald_cursor: s=4bef19b253e44f9a824ad7e1702ab37d;i=3c41fb;b=033ea9e0094343ae98629c679432c48a;m=924e437c;t=583c17a75cb42;x=c4f7f5a6bf153a75
kernel:         4.20.14-200.fc29.x86_64
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 magazine_chain_pop_head at gslice.c:538
 #1 thread_memory_magazine1_alloc at gslice.c:841
 #2 g_slice_alloc at gslice.c:1015
 #3 gst_buffer_new at gstbuffer.c:798
 #4 WebCore::AppendPipeline::pushNewBuffer at /usr/src/debug/webkit2gtk3-2.22.7-1.fc29.x86_64/Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp:808
 #5 WebCore::MediaSourceClientGStreamerMSE::append at /usr/src/debug/webkit2gtk3-2.22.7-1.fc29.x86_64/Source/WebCore/platform/graphics/gstreamer/mse/MediaSourceClientGStreamerMSE.cpp:150
 #6 WebCore::SourceBufferPrivateGStreamer::append at /usr/src/debug/webkit2gtk3-2.22.7-1.fc29.x86_64/x86_64-redhat-linux-gnu/DerivedSources/ForwardingHeaders/wtf/RefCounted.h:46
 #7 WebCore::SourceBuffer::appendBufferTimerFired at /usr/src/debug/webkit2gtk3-2.22.7-1.fc29.x86_64/x86_64-redhat-linux-gnu/DerivedSources/ForwardingHeaders/wtf/DumbPtrTraits.h:41
 #9 WebCore::ThreadTimers::sharedTimerFiredInternal at /usr/src/debug/webkit2gtk3-2.22.7-1.fc29.x86_64/Source/WebCore/platform/ThreadTimers.h:101
 #11 WTF::RunLoop::TimerBase::<lambda(gpointer)>::operator() at /usr/src/debug/webkit2gtk3-2.22.7-1.fc29.x86_64/Source/WTF/wtf/glib/RunLoopGLib.cpp:170
Comment 1 Ryan Farmer 2019-03-10 11:54:29 PDT
Created attachment 364184 [details]
cgroup
Comment 2 Ryan Farmer 2019-03-10 11:55:01 PDT
Created attachment 364185 [details]
core backtrace
Comment 3 Ryan Farmer 2019-03-10 11:55:41 PDT
Created attachment 364186 [details]
cpu info
Comment 4 Ryan Farmer 2019-03-10 11:56:34 PDT
Created attachment 364187 [details]
dso list
Comment 5 Ryan Farmer 2019-03-10 11:57:03 PDT
Created attachment 364188 [details]
environ
Comment 6 Ryan Farmer 2019-03-10 11:57:21 PDT
Created attachment 364189 [details]
exploitable
Comment 7 Ryan Farmer 2019-03-10 11:57:56 PDT
Created attachment 364190 [details]
limits
Comment 8 Ryan Farmer 2019-03-10 11:58:15 PDT
Created attachment 364191 [details]
maps
Comment 9 Ryan Farmer 2019-03-10 11:58:38 PDT
Created attachment 364192 [details]
mountinfo
Comment 10 Ryan Farmer 2019-03-10 11:59:13 PDT
Created attachment 364193 [details]
open fds
Comment 11 Ryan Farmer 2019-03-10 11:59:40 PDT
Created attachment 364194 [details]
proc pid status
Comment 12 Michael Catanzaro 2019-03-12 09:31:48 PDT
I can't reproduce.

I wrote in the downstream bug:

Web process memory corruption. This is going to be hard or impossible to debug. :/

* If you're able to reproduce the crash somehow, that gives us only a vague chance of tracking this down. Otherwise: no chance.

* Actual code bug might be in the surrounding GStreamer MediaPlayer code, or it might be somewhere completely unrelated and the GStreamer code is just getting unlucky. No way to know from the backtrace.

* To catch memory corruption, we can use asan or valgrind. I believe asan is currently broken with WebKit. That means instructing the WebKit UI process to launch the web process under valgrind, which requires a debug build of WebKit (not provided by Fedora, and no guarantee the crash would even occur in a custom build, either) and messing with debug environment variables.

Memory corruption is the absolute worst. Sadly there's nothing actionable here, and getting anything actionable would be hard.