Bug 255398 – [GTK] Crash in GraphicsContextGLGBM::allocateDrawBufferObject

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Michael Catanzaro]

Created attachment 465886 [details]
Full backtrace

Here's yet another random non-reproducible SIGSEGV crash that occurred when loading some page. Note the this=0x0:

#0  WebCore::GBMBufferSwapchain::Buffer::handle() const (this=0x0)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebCore/platform/graphics/gbm/GBMBufferSwapchain.h:100
#1  WebCore::GraphicsContextGLGBM::allocateDrawBufferObject() (this=0x7fef0106c110)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebCore/platform/graphics/gbm/GraphicsContextGLGBM.cpp:305
#2  0x00007fefc23d9260 in WebCore::HTMLCanvasElement::prepareForDisplay() (this=0x7fef21084630)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebCore/html/HTMLCanvasElement.cpp:1059
#3  0x00007fefc21e24f9 in WebCore::Document::prepareCanvasesForDisplayIfNeeded() (this=<optimized out>)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebCore/dom/Document.cpp:9451
#4  0x00007fefc286b4ee in WTF::Function<void (WebCore::Document&)>::operator()(WebCore::Document&) const
    (this=0x7fffe6061828, in=...) at WTF/Headers/wtf/Function.h:82
#5  WebCore::Page::forEachDocumentFromMainFrame(WebCore::LocalFrame const&, WTF::Function<void (WebCore::Document&)> const&) (mainFrame=<optimized out>, functor=...)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebCore/page/Page.cpp:3720
#6  0x00007fefc2865bc1 in WebCore::Page::forEachDocument(WTF::Function<void (WebCore::Document&)> const&) const
    (this=0x7fefb10b0d80, functor=...) at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebCore/page/Page.cpp:3726
#7  WebCore::Page::doAfterUpdateRendering() (this=0x7fefb10b0d80)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebCore/page/Page.cpp:1920
#8  0x00007fefc286572c in WebCore::Page::updateRendering() (this=0x7fefb10b0d80)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebCore/page/Page.cpp:1826
#9  0x00007fefc12225c0 in WebKit::CompositingCoordinator::flushPendingLayerChanges(WTF::OptionSet<WebCore::FinalizeRenderingUpdateFlags>) (this=0x7fefb1100838, flags=...)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CompositingCoordinator.cpp:127
#10 0x00007fefc1227c15 in WebKit::LayerTreeHost::layerFlushTimerFired() (this=0x7fefb1100740)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp:160
#11 WebKit::LayerTreeHost::renderNextFrame(bool) (this=0x7fefb1100740, forceRepaint=false)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/LayerTreeHost.cpp:484
#12 0x00007fefc0ee53de in WebKit::ThreadedDisplayRefreshMonitor::displayRefreshCallback() (this=0x7fefb110ff00)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedDisplayRefreshMonitor.cpp:133
#13 0x00007fefbfa74e23 in WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::$_3::operator()(void*) const
    (userData=0x7fefb110ff38, this=<optimized out>)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WTF/wtf/glib/RunLoopGLib.cpp:177
#14 WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::$_3::__invoke(void*) (userData=0x7fefb110ff38)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WTF/wtf/glib/RunLoopGLib.cpp:169
#15 0x00007fefbfa74161 in WTF::RunLoop::$_0::operator()(_GSource*, int (*)(void*), void*) const
    (source=0x5637b45ad090, callback=0x7fefbfa74d90 <WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::$_3::__invoke(void*)>, userData=0x7fefb110ff38, this=<optimized out>)
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#16 WTF::RunLoop::$_0::__invoke(_GSource*, int (*)(void*), void*)
    (source=0x5637b45ad090, callback=0x7fefbfa74d90 <WTF::RunLoop::TimerBase::TimerBase(WTF::RunLoop&)::$_3::__invoke(void*)>, userData=0x7fefb110ff38) at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WTF/wtf/glib/RunLoopGLib.cpp:45
#17 0x00007fefbc778d49 in g_main_dispatch (context=<optimized out>) at ../glib/gmain.c:3460
#18 g_main_context_dispatch (context=<optimized out>) at ../glib/gmain.c:4200
#19 0x00007fefbc7792a8 in g_main_context_iterate
    (context=0x5637b4219940, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at ../glib/gmain.c:4276
#20 0x00007fefbc77958f in g_main_loop_run (loop=0x5637b423caa0) at ../glib/gmain.c:4479
#21 0x00007fefbfa74746 in WTF::RunLoop::run() ()
    at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WTF/wtf/glib/RunLoopGLib.cpp:108
#22 0x00007fefc1237217 in WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (this=0x7fffe6061be0, argc=3, argv=0x7fffe6061d78) at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebKit/Shared/AuxiliaryProcessMain.h:71
#23 WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainGtk>(int, char**) (argc=3, argv=0x7fffe6061d78) at /buildstream/gnome/sdk/webkitgtk-6.0.bst/Source/WebKit/Shared/AuxiliaryProcessMain.h:97
#24 0x00007fefc002954a in __libc_start_call_main (main=main@entry=0x5637b3e52150 <main>, argc=argc@entry=3, argv=argv@entry=0x7fffe6061d78) at ../sysdeps/nptl/libc_start_call_main.h:58
#25 0x00007fefc002960b in __libc_start_main_impl (main=0x5637b3e52150 <main>, argc=3, argv=0x7fffe6061d78, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:389
#26 0x00005637b3e52085 in _start ()

Full backtrace attached.

[Michael Catanzaro]

This seems to be one of our most frequent crashers currently.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #0)
> Created attachment 465886 [details]
> Full backtrace
> 
> Here's yet another random non-reproducible SIGSEGV crash that occurred when
> loading some page. Note the this=0x0:

Oooh, I figured out that it happens when viewing this page:

https://www.riverfronttimes.com/news/i-challenged-st-louis-officials-to-go-car-free-for-one-day-40076892

It's not 100% reproducible but if you stay on the page for a while, maybe scroll up and down, it should hopefully crash eventually. Hit it twice just now.

[Michael Catanzaro]

Hit twice more in two minutes. This is a good reproducer.

[Carlos Garcia Campos]

Pull request: https://github.com/WebKit/WebKit/pull/14066

[Zan Dobersek]

(In reply to Carlos Garcia Campos from comment #4)
> Pull request: https://github.com/WebKit/WebKit/pull/14066

Why is a null buffer returned?

[Carlos Garcia Campos]

(In reply to Zan Dobersek from comment #5)
> (In reply to Carlos Garcia Campos from comment #4)
> > Pull request: https://github.com/WebKit/WebKit/pull/14066
> 
> Why is a null buffer returned?

I don't know, I can't reproduce it, that's why I added the error messages for the situations in which getBuffer can return nullptr. In any case, getBuffer() can return nullptr, so we should either handle the case in callers if that's expected (and it's indeed already handled in other caller), or turn those into asserts if they are unexpected.

[Michael Catanzaro]

(In reply to Zan Dobersek from comment #5)
> Why is a null buffer returned?

Testing the pull request, I see that now instead of crashing, we get an error message:

Failed to get GBM buffer from swap chain: no buffers available

[EWS]

Committed 264648@main (153153309cef): <https://commits.webkit.org/264648@main>

Reviewed commits have been landed. Closing PR #14066 and removing active labels.

[Michael Catanzaro]

Unfortunately another user has reported this same crash using WebKitGTK 2.40.3 (which has the backported fix) in bug #258831, so looks like it's not fixed after all. I considered marking that bug as a duplicate of this one and reopening this one, but decided to wait to see what you (Carlos Garcia and Zan) prefer to do with it.