flypig.co.uk

This morning the build has completed, but I didn't have a chance to work on it before work. So by the time I'm writing this it's already evening. You may recall that yesterday I was trying to avoid a crash after disabling the loading of embedhelper.js. Having installed the packages that built overnight and given them a spin, I'm still getting a crash, and frustratingly it's coming from the same place and happening for exactly the same reason. It's time for more backtraces I'm afraid.

Thread 8 "GeckoWorkerThre" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 5050]
mozilla::embedlite::BrowserChildHelper::DispatchMessageManagerMessage
    (this=0x7f885ddf80, aMessageName=..., aJSONData=...)
    at mobile/sailfishos/utils/BrowserChildHelper.cpp:219
219	  RefPtr mm = kungFuDeathGrip->GetMessageManager();
(gdb) bt
#0  mozilla::embedlite::BrowserChildHelper::DispatchMessageManagerMessage
    (this=0x7f885ddf80, aMessageName=..., aJSONData=...)
    at mobile/sailfishos/utils/BrowserChildHelper.cpp:219
#1  0x0000007fbcc861f4 in mozilla::embedlite::EmbedLiteViewChild::RecvAsyncMessage
    (this=0x7f885d6e20, aMessage=..., aData=...)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/mozilla/RefPtr.h:313
#2  0x0000007fba30b5b8 in mozilla::embedlite::PEmbedLiteViewChild::OnMessageReceived
    (this=0x7f885d6e20, msg__=...) at PEmbedLiteViewChild.cpp:2560
[...]
#30 0x0000007fb79cf89c in ?? () from /lib64/libc.so.6
(gdb) p mBrowserChildMessageManager
$1 = {mRawPtr = 0x0}
(gdb) 

Rather than digging down into this any further I've decided to add a null check instead. It's only a temporary thing after all. I'll do this by adding the following code into the BrowserChildHelper::DispatchMessageManagerMessage() method:

  if (NS_WARN_IF(!mBrowserChildMessageManager)) {
    return;
  }

A quick partial build later and I've transferred the new library over to my phone.

With this change it looks like not all messages are now travelling between the gecko library and the user interface chrome. But it doesn't crash any more. I'm not completely certain this is an improvement (in terms of figuring out rendering issues). So I've reluctantly decided to revert the change that necessitated this in qtmozembed.

Having reverted it I've no built myself some fresh packages and installed them. With that all in place I need to go back to checking the Active/Suspect/Resume status again.

Unfortunately it has been a very long day at work today, so I'm going to have to continue with that tomorrow. I'm frustrated at the lack of progress, but also more convinced then ever that it'll get there.

As always, if you'd like to read more about all this gecko stuff, do take a look at my full Gecko Dev Diary.