[Webkit-unassigned] [Bug 214812] [GStreamer] UI process crash during user media permission request calling gst_v4l2_open() in UI process

Thu Feb 4 10:37:04 PST 2021

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

Michael Catanzaro <mcatanzaro at gnome.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.webkit.org/sho
                   |                            |w_bug.cgi?id=221333

--- Comment #10 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Michael Catanzaro from comment #7)
> Ah I figured it out, there is a symbol conflict between boringssl and
> openssl:

Fixed in bug #221333.

With that fixed, I tested my reproducer for this issue again:

(In reply to Michael Catanzaro from comment #1)
> OK, I have a reproducer for this one: visit my permanent BlueJeans meeting
> (link available privately on request) with webcam unplugged, then plug in
> the webcam. Crash is guaranteed.

However, this time the web process crashes even sooner:

Video capture was requested but no device was found amongst 0 devices
IntConstraint 1, min -1, max -1, exact -1, ideal 640
IntConstraint 2, min -1, max -1, exact -1, ideal 480
DoubleConstraint 4, min -1.000000, max -1.000000, exact -1.000000, ideal 30.000000
MediaConstraint 5 of type 4
malloc_consolidate(): unaligned fastbin chunk detected

The last line looks bad. Looking at the backtrace, it's clearly memory corruption:

(gdb) bt
#0  0x00007f17f44169d5 in raise () from /lib64/libc.so.6
#1  0x00007f17f43ff8a4 in abort () from /lib64/libc.so.6
#2  0x00007f17f4458f27 in __libc_message () from /lib64/libc.so.6
#3  0x00007f17f4460c1c in malloc_printerr () from /lib64/libc.so.6
#4  0x00007f17f4461cc4 in malloc_consolidate () from /lib64/libc.so.6
#5  0x00007f17f4463b73 in _int_malloc () from /lib64/libc.so.6
#6  0x00007f17f44648f7 in malloc_check () from /lib64/libc.so.6
#7  0x00007f17f47af959 in operator new (sz=sz at entry=1024) at ../../../../libstdc++-v3/libsupc++/new_op.cc:50
#8  0x00007f17f81bef3f in __gnu_cxx::new_allocator<std::pair<char*, unsigned long> >::allocate (__n=<optimized out>, 
    this=<optimized out>) at /usr/include/c++/10/ext/new_allocator.h:103
#9  std::allocator_traits<std::allocator<std::pair<char*, unsigned long> > >::allocate (__a=..., __n=<optimized out>)
    at /usr/include/c++/10/bits/alloc_traits.h:460
#10 std::_Vector_base<std::pair<char*, unsigned long>, std::allocator<std::pair<char*, unsigned long> > >::_M_allocate (__n=<optimized out>, this=<optimized out>) at /usr/include/c++/10/bits/stl_vector.h:346
#11 std::vector<std::pair<char*, unsigned long>, std::allocator<std::pair<char*, unsigned long> > >::_M_realloc_insert<std::pair<char*, unsigned long> > (this=this at entry=0x7f17e39ff9d8, __position=
  {first = 0x1a <error: Cannot access memory at address 0x1a>, second = 0})
    at /usr/include/c++/10/bits/vector.tcc:440
#12 0x00007f17f81bb70e in std::vector<std::pair<char*, unsigned long>, std::allocator<std::pair<char*, unsigned long> > >::emplace_back<std::pair<char*, unsigned long> > (this=0x7f17e39ff9d8) at /usr/include/c++/10/bits/vector.tcc:121
#13 std::vector<std::pair<char*, unsigned long>, std::allocator<std::pair<char*, unsigned long> > >::push_back (
    __x=..., this=0x7f17e39ff9d8) at /usr/include/c++/10/bits/stl_vector.h:1204
#14 bmalloc::BulkDecommit::add (this=0x7f17e39ff9c0, size=<optimized out>, ptr=<optimized out>, 
    data=std::vector of length 32, capacity 32 = {...}) at ../../Source/bmalloc/bmalloc/BulkDecommit.h:61
#15 bmalloc::BulkDecommit::addLazy (size=<optimized out>, ptr=<optimized out>, this=0x7f17e39ff9c0)
    at ../../Source/bmalloc/bmalloc/BulkDecommit.h:43
#16 bmalloc::Heap::decommitLargeRange (this=this at entry=0x7f17f9633000, range=..., decommitter=...)
    at ../../Source/bmalloc/bmalloc/Heap.cpp:111
#17 0x00007f17f81bbf77 in bmalloc::Heap::scavenge (this=0x7f17f9633000, lock=..., decommitter=..., 
    deferredDecommits=@0x7f17e39ff988: 4) at ../../Source/bmalloc/bmalloc/Heap.cpp:169
#18 0x00007f17f81c1529 in bmalloc::Scavenger::scavenge (
    this=0x7f17f8538aa0 <bmalloc::StaticPerProcessStorageTraits<bmalloc::Scavenger>::Storage::s_memory>)
    at ../../Source/bmalloc/bmalloc/Scavenger.cpp:233
#19 bmalloc::Scavenger::scavenge (
    this=0x7f17f8538aa0 <bmalloc::StaticPerProcessStorageTraits<bmalloc::Scavenger>::Storage::s_memory>)
    at ../../Source/bmalloc/bmalloc/Scavenger.cpp:205
#20 0x00007f17f81c18e9 in bmalloc::Scavenger::threadRunLoop (
    this=0x7f17f8538aa0 <bmalloc::StaticPerProcessStorageTraits<bmalloc::Scavenger>::Storage::s_memory>)
    at ../../Source/bmalloc/bmalloc/Scavenger.cpp:500
#21 0x00007f17f81c1ce9 in bmalloc::Scavenger::threadEntryPoint (scavenger=<optimized out>)
    at ../../Source/bmalloc/bmalloc/Scavenger.cpp:395
#22 0x00007f17f47db5f4 in std::execute_native_thread_routine (__p=0xf533a0)
    at ../../../../../libstdc++-v3/src/c++11/thread.cc:80
#23 0x00007f17f49b63f9 in start_thread () from /lib64/libpthread.so.0
#24 0x00007f17f44da903 in clone () from /lib64/libc.so.6

I tried again with G_SLICE=always-malloc Malloc=1 and found something a bit nicer:

#0  0x00007f19159999d5 in raise () from /lib64/libc.so.6
#1  0x00007f19159828a4 in abort () from /lib64/libc.so.6
#2  0x00007f19159dbf27 in __libc_message () from /lib64/libc.so.6
#3  0x00007f19159e3c1c in malloc_printerr () from /lib64/libc.so.6
#4  0x00007f19159e4cc4 in malloc_consolidate () from /lib64/libc.so.6
#5  0x00007f19159e6b73 in _int_malloc () from /lib64/libc.so.6
#6  0x00007f19159e78f7 in malloc_check () from /lib64/libc.so.6
#7  0x00007f1915fbabe6 in g_malloc (n_bytes=3991) at ../../../../Projects/glib/glib/gmem.c:106
#8  0x00007f1915fd5f3b in g_slice_alloc (mem_size=3991) at ../../../../Projects/glib/glib/gslice.c:1069
#9  0x00007f19151b870f in _sysmem_new_block (flags=0, maxsize=3847, align=7, offset=0, size=3840)
    at ../gst/gstallocator.c:413
#10 0x00007f19151c59ae in gst_buffer_new_allocate (allocator=0x0 [GstAllocator], size=3840, 
    params=params at entry=0xa444878) at ../gst/gstbuffer.c:891
#11 0x00007f19153016bb in default_prepare_output_buffer (trans=0xa4448c0 [GstAudioConvert|audioconvert], 
    inbuf=0x8c4d590 [GstBuffer], outbuf=0x7f185e32b7a0) at ../libs/gst/base/gstbasetransform.c:1704
#12 0x00007f1894523ddb in gst_audio_convert_prepare_output_buffer (base=0xa4448c0 [GstAudioConvert|audioconvert], 
    inbuf=0x8c4d590 [GstBuffer], outbuf=0x7f185e32b7a0) at ../gst/audioconvert/gstaudioconvert.c:938
#13 0x00007f19153097d8 in default_generate_output (trans=0xa4448c0 [GstAudioConvert|audioconvert], 
    outbuf=0x7f185e32b7a0) at ../libs/gst/base/gstbasetransform.c:2159
#14 0x00007f1915309f54 in gst_base_transform_chain (pad=<optimized out>, 
    parent=0xa4448c0 [GstAudioConvert|audioconvert], buffer=0x7f185e32b7a0 [None])
    at ../libs/gst/base/gstbasetransform.c:2341
#15 0x00007f19152038ad in gst_pad_chain_data_unchecked (pad=pad at entry=0xa444e00 [GstPad|sink], type=type at entry=4112, 
    data=data at entry=0x8c4d590) at ../gst/gstpad.c:4399
#16 0x00007f1915206de9 in gst_pad_push_data (pad=pad at entry=0xa4443d0 [GstPad|src], type=type at entry=4112, 
    data=data at entry=0x8c4d590) at ../gst/gstpad.c:4655
#17 0x00007f19152071fe in gst_pad_push (pad=0xa4443d0 [GstPad|src], buffer=buffer at entry=0x8c4d590 [GstBuffer])
    at ../gst/gstpad.c:4774
#18 0x00007f18935a23eb in gst_queue_push_one (queue=0xa443940 [GstQueue|queue])
    at ../plugins/elements/gstqueue.c:1386
#19 gst_queue_loop (pad=<optimized out>) at ../plugins/elements/gstqueue.c:1539
#20 0x00007f191522d487 in gst_task_func (task=0xa44af20 [GstTask|queue:src]) at ../gst/gsttask.c:328
#21 0x00007f1915fe5611 in g_thread_pool_thread_proxy (data=0x9fe9060)
    at ../../../../Projects/glib/glib/gthreadpool.c:354
#22 0x00007f1915fe4ee4 in g_thread_proxy (data=0xa44b000) at ../../../../Projects/glib/glib/gthread.c:826
#23 0x00007f1916016259 in linux_pthread_proxy (data=0xa44b000) at ../../../../Projects/glib/glib/gthread-posix.c:1259
#24 0x00007f1915f393f9 in start_thread () from /lib64/libpthread.so.0
#25 0x00007f1915a5d903 in clone () from /lib64/libc.so.6

There might be a problem in that code? But since it's memory corruption, that could be pointing to innocent unlucky code rather than the real source of the bug. I tried running the web process under valgrind:

$ jhbuild run env WEB_PROCESS_CMD_PREFIX="valgrind --track-origins=yes" G_SLICE=always-malloc Malloc=1 WEBKIT_FORCE_SANDBOX=0 GIGACAGE_ENABLED=0 epiphany

But it's so slow that I eventually gave up.

-- 
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/20210204/8cf940f8/attachment-0001.htm>