flypig.co.uk

It's been just a short day of development today. After discovering the source of the browser crashes yesterday, I've been collecting evidence to try to find out where the WebView rendering path and the WebGL rendering path need to diverge.

To do this, I'm going to add breakpoints to the SwapChain and GLScreenBuffer constructors. Why these? Because SwapChain is what allows WebGL to work while breaking the WebView, whereas GLScreenBuffer allows the WebView to work but breaks WebGL. Somewhere between these two lies a sweet spot that we have to inhabit.

First up, the breakpoints for sailfish-browser:

(gdb) info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <PENDING>  SwapChain::SwapChain
2       breakpoint     keep y   <PENDING>  GLScreenBuffer::GLScreenBuffer

Executing this and showing a page that renders some WebGL content, we quickly hit the first of these breakpoints:

Thread 8 "GeckoWorkerThre" hit Breakpoint 1, mozilla::gl::SwapChain::
    SwapChain (this=0x7fc95168f8)
    at gfx/gl/GLScreenBuffer.h:63
63      class SwapChain final {
(gdb) bt
#0  mozilla::gl::SwapChain::SwapChain (this=0x7fc95168f8)
    at gfx/gl/GLScreenBuffer.h:63
#1  0x0000007ff3699528 in mozilla::WebGLContext::WebGLContext (
    this=0x7fc9516460, host=..., desc=...)
    at include/c++/8.3.0/bits/move.h:74
#2  0x0000007ff36a8c6c in mozilla::WebGLContext::<lambda()>::operator() (
    __closure=<optimized out>)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/cxxalloc.h:33
#3  mozilla::WebGLContext::Create (host=..., desc=..., 
    out=out@entry=0x7fc9516068)
    at dom/canvas/WebGLContext.cpp:562
#4  0x0000007ff36608fc in mozilla::HostWebGLContext::Create (ownerData=..., 
    desc=..., out=out@entry=0x7fc9516068)
    at dom/canvas/HostWebGLContext.cpp:59
#5  0x0000007ff3690350 in mozilla::ClientWebGLContext::<lambda()>::operator() (
    __closure=<optimized out>)
    at dom/canvas/ClientWebGLContext.cpp:625
#6  mozilla::ClientWebGLContext::CreateHostContext (
    this=this@entry=0x7ee01d6150, requestedSize=...)
    at dom/canvas/ClientWebGLContext.cpp:654
#7  0x0000007ff3690e38 in mozilla::ClientWebGLContext::SetDimensions (
    this=0x7ee01d6150, signedWidth=<optimized out>, signedHeight=<optimized 
    out>)
    at dom/canvas/ClientWebGLContext.cpp:563
#8  0x0000007ff362a1ec in mozilla::dom::CanvasRenderingContextHelper::
    UpdateContext (this=0x7fc94782c0, aCx=<optimized out>, 
    aNewContextOptions=..., 
    aRvForDictionaryInit=...)
    at dom/canvas/CanvasRenderingContextHelper.cpp:238
#9  0x0000007ff36392b8 in mozilla::dom::CanvasRenderingContextHelper::
    GetContext (this=this@entry=0x7fc94782c0, aCx=0x7fc8222fa0, aContextId=..., 
    aContextOptions=..., aRv=...)
    at dom/canvas/CanvasRenderingContextHelper.cpp:190
#10 0x0000007ff390aef4 in mozilla::dom::HTMLCanvasElement::GetContext (
    this=this@entry=0x7fc9478240, aCx=aCx@entry=0x7fc8222fa0, aContextId=..., 
    aContextOptions=aContextOptions@entry=..., aRv=...)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/js/Value.h:670
#11 0x0000007ff35486d4 in mozilla::dom::HTMLCanvasElement_Binding::getContext (
    cx=0x7fc8222fa0, obj=..., void_self=0x7fc9478240, args=...)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/js/RootingAPI.h:1297
#12 0x0000007ff35dfb5c in mozilla::dom::binding_detail::GenericMethod<mozilla::
    dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::
    ThrowExceptions> (cx=0x7fc8222fa0, argc=<optimized out>, vp=<optimized out>)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/js/CallArgs.h:207
[..]
#63 0x0000007fefbae89c in ?? () from /lib64/libc.so.6
(gdb) 

Next up, the same arrangement with harbour-webview. Here are the breakpoints again:

(gdb) info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <PENDING>  SwapChain::SwapChain
2       breakpoint     keep y   <PENDING>  GLScreenBuffer::GLScreenBuffer

This time it's the GLScreenBuffer code that gets hit. This is what I was expecting, although I wasn't expecting it to be the GLScreenBuffer::Size() method. In fact, on closer inspection it's not our breakpoint being hit at all, but rather a segmentation fault that happens to relate to the GLScreenBuffer code:

Thread 38 "Compositor" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 14178]
0x0000007ff366520c in mozilla::gl::GLScreenBuffer::Size (this=0x0)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/UniquePtr.h:290
290     ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/UniquePtr.h: No 
    such file or directory.
(gdb) bt
#0  0x0000007ff366520c in mozilla::gl::GLScreenBuffer::Size (this=0x0)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/UniquePtr.h:290
#1  mozilla::embedlite::EmbedLiteCompositorBridgeParent::
    CompositeToDefaultTarget (this=0x7fc4b7ede0, aId=...)
    at mobile/sailfishos/embedthread/EmbedLiteCompositorBridgeParent.cpp:151
#2  0x0000007ff12b5448 in mozilla::layers::CompositorVsyncScheduler::
    ForceComposeToTarget (this=0x7fc4c37f90, aTarget=aTarget@entry=0x0, 
    aRect=aRect@entry=0x0)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/layers/LayersTypes.h:
    82
#3  0x0000007ff12b54a4 in mozilla::layers::CompositorBridgeParent::
    ResumeComposition (this=this@entry=0x7fc4b7ede0)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/RefPtr.h:313
#4  0x0000007ff12b5530 in mozilla::layers::CompositorBridgeParent::
    ResumeCompositionAndResize (this=0x7fc4b7ede0, x=<optimized out>, 
    y=<optimized out>, 
    width=<optimized out>, height=<optimized out>)
    at gfx/layers/ipc/CompositorBridgeParent.cpp:794
#5  0x0000007ff12ae0cc in mozilla::detail::RunnableMethodArguments<int, int, 
    int, int>::applyImpl<mozilla::layers::CompositorBridgeParent, void (mozilla:
    :layers::CompositorBridgeParent::*)(int, int, int, int), 
    StoreCopyPassByConstLRef<int>, StoreCopyPassByConstLRef<int>, 
    StoreCopyPassByConstLRef<int>, StoreCopyPassByConstLRef<int>, 0ul, 1ul, 
    2ul, 3ul> (args=..., m=<optimized out>, o=<optimized out>)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsThreadUtils.h:1151
[...]
#17 0x0000007ff6a0289c in ?? () from /lib64/libc.so.6
(gdb) 

The next step has to be to fix this segmentation fault, which looks like it's happening precisely because GLScreenBuffer hasn't been constructed yet. But that'll have to be a task for tomorrow now.

If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.