List items
Items from the current list are shown below.
Blog
7 Mar 2024 : Day 178 #
Good morning! Well, it is for me at least. By the time this gets posted it'll be the evening. But for me right now it's early and when I check in on my laptop I can see that the build has completed.
We'll take a look at the build presently, but before we do, thank you to Adam Pigg (piggz) for commenting on my meander into virtual methods yesterday. As Adam rightly pointed out, my C++ code was missing some accoutrements that he'd have preferred to see included.
Adam is right of course, not only are these sensible ways to improve the code, but the use of override would also have improved clarity. Adam has kindly provide his own, improved, version of the code which I'll share below. He then went on to make a few, perhaps more controversial, suggestions"
I'll leave it to the reader to judge whether these would actually be improvements or not. Here's Adam's updated version of the code. One thing to note is that support for C++23's std::print requires at least GCC 14 or Clang 18 if you want to compile this at home, but Adam has confirmed it all works as expected using the online Godbolt Compiler Explorer.
The latest Gecko build incorporates all of the GLScreenBuffer code that I've been adding in and following changes made yesterday should also now no longer make use of the SwapChain class. I've copied the packages over to my development phone, installed them and now it's time to test them.
Looking through the ESR 78 code there's only one place I can discern that sets the mScreen variable and that's this one:
Let's continue digging backwards and find out where InitOffscreen() gets called. It turns out it's called in quite a few places:
We're building up a pretty clear path for how mScreen ends up initialised in ESR 78. The CreateContext() method is the first time we've reached something on this path which also exists in ESR 91. So this would seem to be a good place to switch back to ESR 91 and try to reconstruct the path in the opposite direction.
Just to make sure we're not being led in the wrong direction, it's also worth checking that CreateContext() is actually being called in ESR 91 and that this is happening before the segmentation fault causes the application to crash.
So the next step is to add the CreateOffscreen() code to GLContextProviderEGL. There's code in ESR 78 to copy over, so that part's straightforward. However various interfaces it makes use of have been changed or are missing. I've had to make some quite heavy, but nevertheless justifiable, changes to the code. For example the GLLibraryEGL::EnsureInitialized() method has been replaced by GLLibraryEGL::Init(). That's more than just a name change: the former can be safely called multiple times, whereas the latter can only be called once (or so it appears). Consequently I've removed the call entirely, on the assumption that the Init() method is being called somewhere else. We'll find out whether that's true or not when we come to execute the program.
Nevertheless the partial builds now compile, so it's time to run the full build again, which will take more hours than there are left in the day. So we'll return to this again tomorrow.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
We'll take a look at the build presently, but before we do, thank you to Adam Pigg (piggz) for commenting on my meander into virtual methods yesterday. As Adam rightly pointed out, my C++ code was missing some accoutrements that he'd have preferred to see included.
Sorry, but i have to deduct points for using raw pointers and not smart pointers, and missing the override keyword ;)
Adam is right of course, not only are these sensible ways to improve the code, but the use of override would also have improved clarity. Adam has kindly provide his own, improved, version of the code which I'll share below. He then went on to make a few, perhaps more controversial, suggestions"
I'd also drop using namespace, and maybe mix in some C++23, and swap cout for std::print 🙃
I'll leave it to the reader to judge whether these would actually be improvements or not. Here's Adam's updated version of the code. One thing to note is that support for C++23's std::print requires at least GCC 14 or Clang 18 if you want to compile this at home, but Adam has confirmed it all works as expected using the online Godbolt Compiler Explorer.
#includeThanks for that Adam! I'm always up for a bit of blog-based code review. Okay, now back to the Gecko changes from yesterday.#include #include class Parent { public: virtual ~Parent() {}; std::string hello() { return std::string("Hello son"); } std::string wave() { return std::string("Waves"); } virtual std::string goodbye() { return std::string("Goodbye son"); } }; class Child : public Parent { public: std::string hello() { return std::string("Hello Mum"); } std::string goodbye() override { return std::string("Goodbye Mum"); } }; int main() { std::unique_ptr parent(new Parent); std::shared_ptr child = std::make_shared (); std::shared_ptr vparent = std::dynamic_pointer_cast (child); std::println("1. {} ", parent->hello()); std::println("2. {} ", child->hello()); std::println("3. {} ", vparent->hello()); std::println("4. {} ", parent->wave()); std::println("5. {} ", child->wave()); std::println("6. {} ", vparent->wave()); std::println("7. {} ", parent->goodbye()); std::println("8. {} ", child->goodbye()); std::println("9. {} ", vparent->goodbye()); std::println("10. {} ", reinterpret_cast (parent.get())); std::println("11. {} ", reinterpret_cast (child.get())); std::println("12. {} ", reinterpret_cast (vparent.get())); return 0; }
The latest Gecko build incorporates all of the GLScreenBuffer code that I've been adding in and following changes made yesterday should also now no longer make use of the SwapChain class. I've copied the packages over to my development phone, installed them and now it's time to test them.
$ gdb harbour-webview GNU gdb (GDB) Mer (8.2.1+git9) [...] (gdb) r [...] =============== Preparing offscreen rendering context =============== [New LWP 20044] Thread 37 "Compositor" received signal SIGSEGV, Segmentation fault. [Switching to LWP 20040] 0x0000007ff110a0a8 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 0x0000007ff110a0a8 in mozilla::gl::GLScreenBuffer::Size (this=0x0) at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/UniquePtr.h:290 #1 mozilla::gl::GLContext::OffscreenSize (this=this@entry=0x7ed419ee40) at gfx/gl/GLContext.cpp:2141 #2 0x0000007ff3666804 in mozilla::embedlite::EmbedLiteCompositorBridgeParent:: CompositeToDefaultTarget (this=0x7fc4ba91a0, aId=...) at mobile/sailfishos/embedthread/EmbedLiteCompositorBridgeParent.cpp:156 #3 0x0000007ff12b6f50 in mozilla::layers::CompositorVsyncScheduler:: ForceComposeToTarget (this=0x7fc4cabe80, aTarget=aTarget@entry=0x0, aRect=aRect@entry=0x0) at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/layers/LayersTypes.h:82 #4 0x0000007ff12b6fac in mozilla::layers::CompositorBridgeParent:: ResumeComposition (this=this@entry=0x7fc4ba91a0) at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/RefPtr.h:313 #5 0x0000007ff12b7038 in mozilla::layers::CompositorBridgeParent:: ResumeCompositionAndResize (this=0x7fc4ba91a0, x=<optimized out>, y=<optimized out>, width=<optimized out>, height=<optimized out>) at gfx/layers/ipc/CompositorBridgeParent.cpp:794 #6 0x0000007ff12afbd4 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 [...] #18 0x0000007ff6a0489c in ?? () from /lib64/libc.so.6 (gdb) frame 1 #1 mozilla::gl::GLContext::OffscreenSize (this=this@entry=0x7ed419ee40) at gfx/gl/GLContext.cpp:2141 2141 return mScreen->Size(); (gdb) p mScreen $1 = { mTuple = {<mozilla::detail::CompactPairHelper<mozilla::gl::GLScreenBuffer*, mozilla::DefaultDelete<mozilla::gl::GLScreenBuffer>, (mozilla::detail::StorageType)1, (mozilla::detail::StorageType)0>> = {<mozilla::DefaultDelete<mozilla::gl::GLScreenBuffer>> = {<No data fields>}, mFirstA = 0x0}, <No data fields>}} (gdb) p mScreen.mTuple.mFirstA $2 = (mozilla::gl::GLScreenBuffer *) 0x0 (gdb)So that's an immediate crash, the reason being that the code is calling the OffScreenSize() method of the mScreen member variable of type GLScreenBuffer, but mScreen is null. That is, it's not been initialised yet.
Looking through the ESR 78 code there's only one place I can discern that sets the mScreen variable and that's this one:
bool GLContext::CreateScreenBufferImpl(const IntSize& size, const SurfaceCaps& caps) { UniquePtr<GLScreenBuffer> newScreen = GLScreenBuffer::Create(this, size, caps); [...] mScreen = std::move(newScreen); return true; }The only place this is called is here:
bool CreateScreenBuffer(const gfx::IntSize& size, const SurfaceCaps& caps) { if (!IsOffscreenSizeAllowed(size)) return false; return CreateScreenBufferImpl(size, caps); }But this is just some indirection. Clearly the method we're really interested in is CreateScreenBuffer(). This is also only called in one place:
bool GLContext::InitOffscreen(const gfx::IntSize& size, const SurfaceCaps& caps) { if (!CreateScreenBuffer(size, caps)) return false; [...] mCaps = mScreen->mCaps; MOZ_ASSERT(!mCaps.any); return true; }It's worth noticing here that soon after calling the CreateScreenBuffer() method and in the same call, the mCaps member of mScreen is being accessed. If mScreen were null at the time of this access, this would immediately trigger a segmentation fault. So clearly, by the end of the InitOffscreen() method, it's expected that mScreen should be a valid instance of GLScreenBuffer.
Let's continue digging backwards and find out where InitOffscreen() gets called. It turns out it's called in quite a few places:
$ grep -rIn "InitOffscreen(" * --include="*.cpp" gecko-dev/gfx/gl/GLContextProviderGLX.cpp:1035: if (!gl->InitOffscreen(size, minCaps)) { gecko-dev/gfx/gl/GLContextProviderWGL.cpp:532: if (!gl->InitOffscreen(size, minCaps)) return nullptr; gecko-dev/gfx/gl/GLContextProviderEGL.cpp:1443: if (!gl->InitOffscreen(size, minOffscreenCaps)) { gecko-dev/gfx/gl/GLContext.cpp:2576: bool GLContext::InitOffscreen(const gfx::IntSize& size,The only one of these context providers we care about, given it's the only one used by sailfish-browser, is GLContextProviderEGL. The instance in GLContext.cpp is the method definition so we can ignore that. So there's only one case to concern ourselves with. The call in GLContextProviderEGL occurs in the GLContextProviderEGL::CreateOffscreen() method, which is rather long so I won't list the entire contents here. Suffice it to say that this is the call we need to be finding some equivalent of in ESR 91. This itself is only called from CompositorOGL::CreateContext().
We're building up a pretty clear path for how mScreen ends up initialised in ESR 78. The CreateContext() method is the first time we've reached something on this path which also exists in ESR 91. So this would seem to be a good place to switch back to ESR 91 and try to reconstruct the path in the opposite direction.
Just to make sure we're not being led in the wrong direction, it's also worth checking that CreateContext() is actually being called in ESR 91 and that this is happening before the segmentation fault causes the application to crash.
(gdb) b CompositorOGL::CreateContext Breakpoint 1 at 0x7ff119a348: file gfx/layers/opengl/CompositorOGL.cpp, line 227. (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/bin/harbour-webview [...] Thread 38 "Compositor" hit Breakpoint 1, mozilla::layers::CompositorOGL:: CreateContext (this=this@entry=0x7ed8002f10) at gfx/layers/opengl/CompositorOGL.cpp:227 227 already_AddRefed<mozilla::gl::GLContext> CompositorOGL::CreateContext() { (gdb)Yes, it looks to be the case. So now back to building the path. The call to CreateOffscreen() in ESR 78 has been replaced by a call to CreateHeadless() in ESR 91. This is code we've looked at before, but finally we're getting to unravel it a bit. Here's the ESR 78 version:
SurfaceCaps caps = SurfaceCaps::ForRGB(); caps.preserve = false; caps.bpp16 = gfxVars::OffscreenFormat() == SurfaceFormat::R5G6B5_UINT16; nsCString discardFailureId; context = GLContextProvider::CreateOffscreen( mSurfaceSize, caps, CreateContextFlags::REQUIRE_COMPAT_PROFILE, &discardFailureId);And here's the equivalent code, also executed from within CompositorOGL::CreateContext(), from ESR 91.
nsCString discardFailureId; context = GLContextProvider::CreateHeadless( {CreateContextFlags::REQUIRE_COMPAT_PROFILE}, &discardFailureId); if (!context->CreateOffscreenDefaultFb(mSurfaceSize)) { context = nullptr; }This gives us all the pieces we need — both mSurfaceSize and caps are available in ESR 91 — so we just need to reconstruct the call to reflect what's happening in ESR 78.
So the next step is to add the CreateOffscreen() code to GLContextProviderEGL. There's code in ESR 78 to copy over, so that part's straightforward. However various interfaces it makes use of have been changed or are missing. I've had to make some quite heavy, but nevertheless justifiable, changes to the code. For example the GLLibraryEGL::EnsureInitialized() method has been replaced by GLLibraryEGL::Init(). That's more than just a name change: the former can be safely called multiple times, whereas the latter can only be called once (or so it appears). Consequently I've removed the call entirely, on the assumption that the Init() method is being called somewhere else. We'll find out whether that's true or not when we come to execute the program.
Nevertheless the partial builds now compile, so it's time to run the full build again, which will take more hours than there are left in the day. So we'll return to this again tomorrow.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
Comments
Uncover Disqus comments