Bug 199403 – [GTK] Crash in WebCore::ScrollView::paint

• Component: Layout and Rendering
• Status: NEW

[Michael Catanzaro]

Created attachment 373318 [details]
Backtrace

Truncated backtrace:
Thread no. 1 (8 frames)
 #0 WebCore::ScrollView::paint at ../Source/WebCore/platform/Widget.h:225
 #1 WebKit::WebPage::drawRect at DerivedSources/ForwardingHeaders/wtf/DumbPtrTraits.h:41
 #2 WebKit::DrawingAreaCoordinatedGraphics::display at /usr/include/c++/9/bits/unique_ptr.h:357
 #4 WTF::RunLoop::TimerBase::<lambda(gpointer)>::operator() at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:171
 #5 WTF::RunLoop::TimerBase::<lambda(gpointer)>::_FUN(gpointer) at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:177
 #10 WTF::RunLoop::run at ../Source/WTF/wtf/glib/RunLoopGLib.cpp:96
 #11 WebKit::AuxiliaryProcessMain<WebKit::WebProcess, WebKit::WebProcessMain> at ../Source/WebKit/Shared/unix/AuxiliaryProcessMain.h:47
 #13 _start

Hard to understand what's wrong here unfortunately. My suspicion would be something wrong with DrawingAreaCoordinatedGraphics::display timer, but who knows. Full backtrace attached.

[Zan Dobersek]

This is a non-AC codepath that WPE never uses.

[Carlos Garcia Campos]

My guess is that m_widget is uninitialized in ScrollView, but I'm not sure that can actually happen.

[Michael Catanzaro]

I assume ScrollView itself is already freed, perhaps?

[Michael Catanzaro]

(In reply to Zan Dobersek from comment #1)
> This is a non-AC codepath that WPE never uses.

There is a PLATFORM(WPE) condition in the DrawingAreaCoordinatedGraphics constructor, to set the priority for the display timer differently. If WPE really doesn't use this code, then that condition should go away.

[Michael Catanzaro]

This backtrace is really frustrating because the line numbers are all std::unique_ptr nonsense, very unhelpful. :/ There are only a few function calls in WebKit::DrawingAreaCoordinatedGraphics::display but none of them seem likely to get us to WebKit::WebPage::drawRect?

[Carlos Garcia Campos]

(In reply to Michael Catanzaro from comment #3)
> I assume ScrollView itself is already freed, perhaps?

I would expect it to crash earlier then, in WebKit::WebPage::drawRect()

m_mainFrame->coreFrame()->view()->paint(graphicsContext, rect);

FrameView is owned by Frame, so if it's freed view() should return nullptr and the crash would happen here.

[Carlos Garcia Campos]

(In reply to Michael Catanzaro from comment #5)
> This backtrace is really frustrating because the line numbers are all
> std::unique_ptr nonsense, very unhelpful. :/ There are only a few function
> calls in WebKit::DrawingAreaCoordinatedGraphics::display but none of them
> seem likely to get us to WebKit::WebPage::drawRect?

I think you are looking at the wrong ::display(), it's the one receiving an UpdateInfo&, which indeed calls WebPage::drawRect() in:

for (const auto& rect : rects) {
    m_webPage.drawRect(*graphicsContext, rect);
    updateInfo.updateRects.append(rect);
}

[Carlos Garcia Campos]

This is going to be difficult to fix without a way to reproduce it anyway.