flypig.co.uk

Finally I have my new packages installed and ready to go. My development was disrupted today by the need to have a new keyboard installed in my laptop (the original having been broken from overuse it seems). The technician who came to replace it was highly skilled and incredibly efficient. I was, I have to admit, impressed.

But with the new keyboard in place I'm able to type and develop again, so let's get back to it.

Time to step through the code. Yesterday I was anxious about mDefaultDisplay which gets set, then immediately expires. After pondering this in more detail I concluded that the expiration was inevitable. The value gets stored in a weak pointer without any related shared pointer. It expires immediately.

That's just the logic as it is. So what happens in the previous working version? I've installed my backup copy of the old package and, on testing out this bit of the code, it does exactly the same:

Thread 37 "Compositor" hit Breakpoint 2, mozilla::gl::GLLibraryEGL::
    DefaultDisplay (this=this@entry=0x7ed81a23e0,
    out_failureId=out_failureId@entry=0x7f2e381f60)
    at gfx/gl/GLLibraryEGL.cpp:741
741         nsACString* const out_failureId) {
(gdb) n
742       auto ret = mDefaultDisplay.lock();
(gdb) n
745       ret = CreateDisplay(false, out_failureId);
(gdb)

Interestingly I also discovered while checking this that in the working version CreateDisplay() gets called additional times if there's WebGL content on the page. Alongside the initial creation it also gets called from Init() like this when creating the canvas texture to render to:

Thread 8 "GeckoWorkerThre" hit Breakpoint 1, mozilla::gl::
    GLLibraryEGL::CreateDisplay (this=this@entry=0x7fca67d450, 
    forceAccel=forceAccel@entry=false,
    out_failureId=out_failureId@entry=0x7fdf2ddd18, aDisplay=aDisplay@entry=0x0)
    at gfx/gl/GLLibraryEGL.cpp:752
752         EGLDisplay aDisplay) {
(gdb) bt
#0  mozilla::gl::GLLibraryEGL::CreateDisplay (this=this@entry=0x7fca67d450, 
    forceAccel=forceAccel@entry=false, 
    out_failureId=out_failureId@entry=0x7fdf2ddd18, aDisplay=aDisplay@entry=0x0)
    at gfx/gl/GLLibraryEGL.cpp:752
#1  0x0000007ff28c27e8 in mozilla::gl::GLLibraryEGL::Init (
    this=this@entry=0x7fca67d450, forceAccel=forceAccel@entry=false, 
    out_failureId=out_failureId@entry=0x7fdf2ddd18, aDisplay=aDisplay@entry=0x0)
    at gfx/gl/GLLibraryEGL.cpp:504
[...]

That's interesting. But the conclusion is the same, which is that this particular change isn't causing the crash. I'll need to look elsewhere to fix this.

The crash location after making the most recent changes is still inside wl_proxy_marshal_constructor() which relates to Wayland. I did add a load of code related to Wayland in the last commit, although I'm not totally sure it gets used. Most of it has been added inside the GLContextProviderEGL.cpp file. As I'm looking through it I notice that the GetAppDisplay() method is part of this bundle of code and if I get rid of it, it'd make sense to remove GetAppDisplay() at the same time.

But that will have a knock-on effect, since this is the "source" of the display variable, so to speak. Before this existed, the display value appeared, as if by magic, as the result of the aDisplay parameter of the CreateDisplay() method having a default value set on it. That value being EGL_NO_DISPLAY.

So now I'm wondering what happens if I revert that part and restore this default value again. It's possible that this is where the problem lies: the WebGL is creating a display, using that provided by Wayland and getting in a mess.

I'm not sure, but I'm going to try making this change before getting rid of all the new Wayland code.

The changes I've had to make to get it to compile make me a little uncomfortable, but let's see.

[...]

Having made the changes I still get a crash, and it's in the same location as before. But the code is already now in a better state for me to remove the Wayland changes, so I'm going to do that now and set a build running overnight.

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