flypig.co.uk

Overnight I ran a build having removed the Wayland code added in the last commit, or at least a decent proportion of it. This morning everything was built and it's time to test it out.

Unfortunately we still get a crash. The backtrace isn't identical to the backtrace we were getting a couple of days ago, but it's similar. Similar enough to make me think we've not actually fixed anything yet. Here's the backtrace:

Thread 37 "Compositor" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 25343]
0x0000007fefec60e4 in pthread_mutex_lock () from /lib64/libpthread.so.0
(gdb) bt
#0  0x0000007fefec60e4 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x0000007fe7e34170 in wl_proxy_marshal_array_constructor_versioned () from /
    usr/lib64/libwayland-client.so.0
#2  0x0000007fe7e344e8 in wl_proxy_marshal_constructor () from /usr/lib64/
    libwayland-client.so.0
#3  0x0000007fe7b8442c in ServerWaylandBuffer::ServerWaylandBuffer(unsigned 
    int, unsigned int, int, int, android_wlegl*, wl_event_queue*) ()
   from /usr/lib64/libhybris//eglplatform_wayland.so
#4  0x0000007fe7b844c8 in WaylandNativeWindow::addBuffer() () from /usr/lib64/
    libhybris//eglplatform_wayland.so
#5  0x0000007fe7b83728 in WaylandNativeWindow::dequeueBuffer(
    BaseNativeWindowBuffer**, int*) () from /usr/lib64/libhybris//
    eglplatform_wayland.so
#6  0x0000007fe7b4a124 in BaseNativeWindow::_dequeueBuffer(ANativeWindow*, 
    ANativeWindowBuffer**, int*) () from /usr/lib64/
    libhybris-platformcommon.so.1
#7  0x0000007fe4f69188 in ?? ()
#8  0x0000000000000438 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

So following this I've been working away at the code again. It's mostly business as usual: I continue to remove code, reverting pieces back to the code as it was before my latest commit. I went a bit further than usual today though, removing GLScreenBuffer entirely. That's a really significant change and it required plenty of refinement: fixing up code that made use of it; fixing up code that made use of code that made use of it. Each set of changes brings us a little closer to a working WebGL.

So this turned out to be a really big change. Having made it, I now have to build and test it. It's going to be a short post today, but that reflects the fact I've spent all my time stripping out code. Big changes, but there's not so much to say about it if I'm honest.

I've checked that the partial build goes through. But it's really late now, so I may as well set a full build running overnight. Then I can test the changes in the morning.

The one nice thing about the process I'm currently undertaking with these WebGL changes is that I know that the process is bounded. I have a broken version, I have a working version, I just need to find the tipping point between the two where it switches from broken to fixed. Once I have that it won't be the end of the story, because the changes will inevitably have broken the WebView, but at that point, once I know what's breaking the WebGL, I can go back to the working WebView and reapply that specific change. Or so the theory goes.

Before I sign off for today, I'm going to take a moment to indulge in some development philosophy.

The big difference between detective stories and real life detective work is that in the fictional version the clues are all there, you just need to find them. Real life doesn't come with that guarantee: you can spend your entire life looking for clues that don't exit. I'm sure that's a big part of the reason why, as humans, we prefer computer games over real life. In a computer game we know in advance there's a finite, bounded, solution. A big portion of the uncertainty has already been taken away.

With this particular WebGL bug I'm inhabiting this same happy computer-game place where I know there's a solution, I just have to find it. It may be a slow process, it may be a little arduous at times, but the solution is there, I just need to find it. It exists somewhere between the last commit and the current commit. We'll get there.

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