Created attachment 459617 [details] Test case Since r290375, GStreamer ports are calling gst_deinit() at WebProcess termination. This is causing a deadlock if a MSE SourceBuffer has been instantiated. That is because the GstTask from the appsrc element in the AppendPipeline is still running. The attached test page allows the reproduce the deadlock. It has been adapted from Alicia's test case in bug 191876. To reproduce: ./Tools/Scripts/run-minibrowser --wpe file:///path/to/deadlock-at-exit-if-appendpipeline-started.html & killall MiniBrowser ps You can see that WPEWebProcess is still runing. It is blocked in the gst_deinit() call. Relevant callstacks during the deadlock: Thread 13 (Thread 0x7f99da401700 (LWP 758768)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x00007f9b60f11623 in g_cond_wait () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f9b5e129517 in gst_app_src_create (bsrc=0xc6d850 [GstBaseSrc|appsrc0], offset=<optimized out>, size=4096, buf=0x7f99da400938) at gstappsrc.c:1279 #3 0x00007f9b5e0e34dd in gst_base_src_get_range (src=src@entry=0xc6d850 [GstBaseSrc|appsrc0], offset=offset@entry=0, length=<optimized out>, buf=buf@entry=0x7f99da400a18) at gstbasesrc.c:2527 #4 0x00007f9b5e0e65bc in gst_base_src_loop (pad=0xbc8080 [GstPad|src]) at gstbasesrc.c:2851 #5 0x00007f9b60d04107 in gst_task_func (task=0xbfa3b0 [GstTask|appsrc0:src]) at gsttask.c:328 #6 0x00007f9b60eee374 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #7 0x00007f9b60eedad1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #8 0x00007f9b5e608609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #9 0x00007f9b60831133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7f9b5cbbff80 (LWP 758735)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x00007f9b60f11623 in g_cond_wait () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f9b60eeef4c in g_thread_pool_free () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f9b60d03eed in init_klass_pool (klass=<optimized out>) at gsttask.c:161 #4 0x00007f9b60d04446 in gst_task_cleanup_all () at gsttask.c:381 #5 0x00007f9b60c8487c in gst_deinit () at gst.c:1095 #6 0x00007f9b633f9ae1 in WebKit::WebProcessMainWPE::platformFinalize() (ocEE3endEv=<error reading variable: Unhandled dwarf expression opcode 0x0>) at ../../Source/WebKit/WebProcess/wpe/WebProcessMainWPE.cpp:68 #7 0x00007f9b633f9991 in WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (ocEE3endEv=Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0xe5: #8 0x00007f9b633f8fa0 in WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) (e *, std::unique_ptr<IPC::MessageReceiveQueue, std::default_delete<IPC::MessageReceiveQueue> > > >=Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0xf: #9 0x00007f9b633f8dcb in WebKit::WebProcessMain(int, char**) (e *, std::unique_ptr<IPC::MessageReceiveQueue, std::default_delete<IPC::MessageReceiveQueue> > > >=Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x8c73: #10 0x0000000000401152 in main(int, char**) (argc=3, argv=0x7fff43ca15a8) at ../../Source/WebKit/WebProcess/EntryPoint/unix/WebProcessMain.cpp:31
Pull request: https://github.com/WebKit/WebKit/pull/830
Committed r294634 (250860@main): <https://commits.webkit.org/250860@main> Reviewed commits have been landed. Closing PR #830 and removing active labels.