flypig.co.uk

This morning the new version had fully built. That means it incorporates the changes from yesterday to try to get the use of EglDisplay working correctly. Before I get into the results of the build I want to take you on a brief detour. It was Bonfire Night here in the UK last night, which is the annual celebration of the foiling of a plot to blow up parliament in 1605 in the hope of sparking a Catholic uprising. As celebrations go it's a weirdly parochial and unusually barbaric. But the fireworks and bonfires are completely mesmerising and it's part of the spirit of Autumn that makes me love the season so much.

I mention this for two reasons. First because the entire town where I live was out last night enjoying communal fireworks. Second because I wanted an excuse to share this wonderful image created by Thigg with the help of some AI (or is it the other way around?) that captures some more of what makes Autumn so wonderful.
 
If you've been sticking with the diary you may recall that Thigg also provided a wonderful image to capture activity on Day 46. And also produced some superb images posted to the Sailfish Forum. Such amazing stuff!

Let's return to gecko progress. Unfortunately after installing the packages I built overnight it will no longer run. It doesn't crash, it just stops, apparently dropping out cleanly. If I put breakpoints on the methods that I changed they don't trigger before the app closes, so it's probably not something wrong with the changes I made per se. Instead I suspect it's some broader issue with loading the library.

Let's take a look.

I know that ResolveXPCOMPath inside EmbedInitGlue.cpp gets called early in the startup routine, so I've put a breakpoint on that.

Even that isn't getting called. There are three layers to the browser. The main user-interface wrapper that provides all of the chrome is sailfish-browser. This wraps qtmozembed used for interfacing between Qt and gecko. Finally there's the gecko/xulrunner library itself (libxul.so). That last breakpoint was part of qtmozembed, so I'm going to go one step closer to the application entry point by adding a breakpoint to the sailfish-browser executable instead. The sailfish-browser executable is essentially the first entry point for everything (although there's also the booster, but let's leave that aside).

I've put a breakpoint on main() in sailfish-browser. That is, as a general rule, pretty early when it comes to application start-up.

Finally a hit! The breakpoint on main() works.

(gdb) b main
Breakpoint 4 at 0x555557a868 (2 locations)
(gdb) r
Starting program: /usr/bin/sailfish-browser 
warning: File "/lib64/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

Breakpoint 4, 0x000000555557a868 in main ()
(gdb)

The warnings are normal, nothing that we need to be concerned about. From this point I can now step through to figure out why it's closing so early. But although the breakpoint does fire, stepping inside the main() doesn't get us anywhere as the executable seems to exit before it even gets that far:

(gdb) n
Single stepping until exit from function main,
which has no line number information.
[D] unknown:0 - Using Wayland-EGL
library "libGLESv2_adreno.so" not found
library "eglSubDriverAndroid.so" not found
[New LWP 2484]
[New LWP 2485]
[LWP 2484 exited]
0x0000007fb77ea11c in __libc_start_main () from /lib64/libc.so.6
(gdb) n
Single stepping until exit from function __libc_start_main,
which has no line number information.
[LWP 2485 exited]
[Inferior 1 (process 1896) exited normally]
(gdb) 

Unhelpful.

Well it's rather late now and I'm not sure what's going on here, so I've decided to do a complete rebuild from scratch. The build I performed last night was an incremental build, meaning I didn't delete all the partially built material before performing the build. I've no wiped everything so that the code is in the same state as if I'd just closed it from the repository. It's building now.

Sadly this means no more work on this for today; the build won't complete until the morning at which point I'll try again and see whether anything has changed.

For all the other entries in my developer diary, check out the Gecko-dev Diary page.