Bug 199205

Summary: [GTK] UI process crash in DrawingAreaProxyCoordinatedGraphics::waitForAndDispatchDidUpdateBackingStoreState
Product: WebKit Reporter: Michael Catanzaro <mcatanzaro>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Major CC: bugs-noreply, cdumez, cgarcia, mcatanzaro
Priority: P2    
Version: WebKit Nightly Build   
Hardware: PC   
OS: Linux   
See Also: https://bugs.webkit.org/show_bug.cgi?id=199680
Attachments:
Description Flags
Backtrace none

Description Michael Catanzaro 2019-06-25 14:39:02 PDT
Created attachment 372864 [details]
Backtrace

UI process crash with 2.25.2

Program terminated with signal SIGSEGV, Segmentation fault.
#0  std::__uniq_ptr_impl<IPC::Decoder, std::default_delete<IPC::Decoder> >::_M_ptr (this=0x30)
    at /usr/include/c++/8.3.0/bits/unique_ptr.h:356
356	      explicit operator bool() const noexcept

Truncated backtrace:

#0  0x00007f1c6aa72a2c in std::__uniq_ptr_impl<IPC::Decoder, std::default_delete<IPC::Decoder> >::_M_ptr() const
    (this=0x30) at /usr/include/c++/8.3.0/bits/unique_ptr.h:356
#1  0x00007f1c6aa72a2c in std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >::get() const (this=0x30)
    at /usr/include/c++/8.3.0/bits/unique_ptr.h:343
#2  0x00007f1c6aa72a2c in std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >::operator bool() const
    (this=0x30) at /usr/include/c++/8.3.0/bits/unique_ptr.h:357
#3  0x00007f1c6aa72a2c in IPC::Connection::waitForMessage(IPC::StringReference, IPC::StringReference, unsigned long, WTF::Seconds, WTF::OptionSet<IPC::WaitForOption>)
    (this=this@entry=0x7f1c642cfd00, messageReceiverName=..., messageName=..., destinationID=511, timeout=..., 
    timeout@entry=..., waitForOptions=...) at ../Source/WebKit/Platform/IPC/Connection.cpp:520
#4  0x00007f1c6ac3828e in IPC::Connection::waitForAndDispatchImmediately<Messages::DrawingAreaProxy::DidUpdateBackingStoreState>(unsigned long, WTF::Seconds, WTF::OptionSet<IPC::WaitForOption>)
    (waitForOptions=..., timeout=..., destinationID=<optimized out>, this=0x7f1c642cfd00)
    at ../Source/WebKit/Platform/IPC/StringReference.h:53
#5  0x00007f1c6ac3828e in WebKit::DrawingAreaProxyCoordinatedGraphics::waitForAndDispatchDidUpdateBackingStoreState()
    (this=0x55ba269a7330)
    at ../Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.cpp:344
#6  0x00007f1c6ac3828e in WebKit::DrawingAreaProxyCoordinatedGraphics::waitForAndDispatchDidUpdateBackingStoreState()
    (this=0x55ba269a7330)
    at ../Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.cpp:321
#7  0x00007f1c6ac38820 in WebKit::DrawingAreaProxyCoordinatedGraphics::paint(_cairo*, WebCore::IntRect const&, WebCore::Region&) (this=this@entry=0x55ba269a7330, context=context@entry=0x55ba24c39800, rect=..., unpaintedRegion=...)
    at ../Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.cpp:91
#8  0x00007f1c6ac2a285 in webkitWebViewBaseDraw(GtkWidget*, cairo_t*)
    (widget=0x55ba2f03e830 [EphyWebView], cr=0x55ba24c39800)
    at ../Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:596
#9  0x00007f1c6e15a214 in gtk_widget_draw_internal
    (clip_to_size=1, cr=0x55ba24c39800, widget=0x55ba2f03e830 [EphyWebView]) at gtkwidget.c:7077
#10 0x00007f1c6e15a214 in gtk_widget_draw_internal
    (widget=widget@entry=0x55ba2f03e830 [EphyWebView], cr=cr@entry=0x55ba24c39800, clip_to_size=clip_to_size@entry=1)
    at gtkwidget.c:7015

Full backtrace attached
Comment 1 Michael Catanzaro 2019-06-25 16:05:43 PDT
Well m_waitingForMessage is invalid, but not null (this=0x30). But the local variable waitingForMessage looks fine. I *think* we can conclude that the Connection itself is invalid. DrawingAreaProxyCoordinatedGraphics should probably null-check the connection pointer before using it. Naive solution would be:

    if (Connection* connection = process().connection())
        connection->waitForAndDispatchImmediately<Messages::DrawingAreaProxy::DidUpdateBackingStoreState>(m_identifier.toUInt64(), Seconds::fromMilliseconds(500));

And if that's not right, then at least it should ASSERT(connection) before using it.
Comment 2 Michael Catanzaro 2019-06-25 16:11:48 PDT
(In reply to Michael Catanzaro from comment #1)
> Well m_waitingForMessage is invalid, but not null (this=0x30).

Actually that's wrong, I'm printing it in gdb and it is actually null. It's the decoder that's 0x30. So Connection is valid, but Connection::m_waitingForMessage is null. It shouldn't be possible.
Comment 3 Michael Catanzaro 2019-06-27 07:34:21 PDT
Hm, I hit this UI process crash a second time today. I suspect a recent regression, because I've never noticed this before and UI process crashes are extremely rare nowadays.
Comment 4 Zan Dobersek 2019-07-13 04:47:26 PDT
WPE is not affected.
Comment 5 Carlos Garcia Campos 2019-07-15 06:01:51 PDT
Do you have asserts enabled?
Comment 6 Michael Catanzaro 2019-07-15 07:39:39 PDT
Nope, this is a release build.
Comment 7 Carlos Garcia Campos 2019-07-16 01:06:46 PDT
Looks like a duplicate of #199680.

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