flypig.co.uk

List items

Items from the current list are shown below.

Blog

11 Sep 2023 : Day 26 #
Yesterday we were trying to figure out which old overload of Open() was being used for a particular piece of code, in the hope it would help determine which new overload we should be using instead.

Since I couldn't figure it out just be dredging through the code, it's now time to crack open the debugger to see if it can help us out.

Once again, we're debugging ESR 78 because we don't yet have an executable ESR 91, but for the bit of code we're interested in this doesn't matter because we've not made any changes to it yet.

My aim here is to breakpoint on the call to Open(). The debugger will then tell me exactly which one of the overloaded functions is being called. To ensure I get the right one I've placed a breakpoint on both the Open() call itself and the Init() call containing it. Hence in the debugger output below you'll first see the Init() breakpoint being hit, then immediately after the all-important Open() breakpoint. That second hit should tell us exactly which types are being passed in as parameters.

As previously I've removed some of the output to make things more concise. 
Thread 10 "GeckoWorkerThre" hit Breakpoint 2, EmbedLiteAppChild::Init
    (this=0x7fb89bf4c0, aParentChannel=0x7fb8b12468)
    at mobile/
       sailfishos/embedshared/EmbedLiteAppChild.cpp:75
75	{
(gdb) bt
#0  EmbedLiteAppChild::Init (this=0x7fb89bf4c0, aParentChannel=0x7fb8b12468)
    at mobile/sailfishos/embedshared/EmbedLiteAppChild.cpp:75
#1  0x0000007ff4d83c40 in mozilla::detail::RunnableMethodArguments::applyImpl, 0ul> (args=..., 
    m=, o=) at xpcom/threads/nsThreadUtils.h:1188
[...]
#17 0x0000007fefc41608 in QEventLoop::exec(QFlags) () from /usr/lib64/libQt5Core.so.5
#18 0x0000007fefa864ac in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#19 0x0000007fefa8b0e8 in ?? () from /usr/lib64/libQt5Core.so.5
#20 0x0000007fef971a4c in ?? () from /lib64/libpthread.so.0
#21 0x0000007fef65b89c in ?? () from /lib64/libc.so.6
That's the first breakpoint. Now the second. 
(gdb) c
Continuing.
[New LWP 31927]

Thread 10 "GeckoWorkerThre" hit Breakpoint 1, mozilla::ipc::MessageChannel::Open
    (this=this@entry=0x7fb89bf588, aTargetChan=aTargetChan@entry=0x7fb8b12468,
    aEventTarget=0x55558810a0, aSide=aSide@entry=mozilla::ipc::ChildSide)
    at ipc/glue/MessageChannel.cpp:833
833	                          nsIEventTarget* aEventTarget, Side aSide) {
(gdb) bt
#0  mozilla::ipc::MessageChannel::Open (this=this@entry=0x7fb89bf588,
    aTargetChan=aTargetChan@entry=0x7fb8b12468, aEventTarget=0x55558810a0, 
    aSide=aSide@entry=mozilla::ipc::ChildSide) at ipc/glue/MessageChannel.cpp:833
#1  0x0000007ff22e1900 in mozilla::ipc::IToplevelProtocol::Open
    (this=this@entry=0x7fb89bf4c0, aChannel=aChannel@entry=0x7fb8b12468, 
    aMessageLoop=0x555587b2f0, aSide=aSide@entry=mozilla::ipc::ChildSide)
    at obj-build-mer-qt-xr/dist/include/mozilla/ipc/ProtocolUtils.h:409
#2  0x0000007ff4d8b3c0 in EmbedLiteAppChild::Init
    (this=0x7fb89bf4c0, aParentChannel=0x7fb8b12468)
    at mobile/sailfishos/embedshared/EmbedLiteAppChild.cpp:78
#3  0x0000007ff4d83c40 in mozilla::detail::RunnableMethodArguments::applyImpl, 0ul> (args=..., 
    m=, o=) at xpcom/threads/nsThreadUtils.h:1188
[...]
#19 0x0000007fefc41608 in QEventLoop::exec(QFlags) () from /usr/lib64/libQt5Core.so.5
#20 0x0000007fefa864ac in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#21 0x0000007fefa8b0e8 in ?? () from /usr/lib64/libQt5Core.so.5
#22 0x0000007fef971a4c in ?? () from /lib64/libpthread.so.0
#23 0x0000007fef65b89c in ?? () from /lib64/libc.so.6
(gdb)
And there is our answer: 
mozilla::ipc::MessageChannel::Open (this=this@entry=0x7fb89bf588,
aTargetChan=aTargetChan@entry=0x7fb8b12468, aEventTarget=0x55558810a0, 
aSide=aSide@entry=mozilla::ipc::ChildSide) at ipc/glue/MessageChannel.cpp:833
Or to put it more cleanly: 
bool MessageChannel::Open(MessageChannel* aTargetChan,
                          nsIEventTarget* aEventTarget, Side aSide)
This means that in our new code the equivalent call must be the following: 
bool MessageChannel::Open(MessageChannel* aTargetChan,
                          nsISerialEventTarget* aEventTarget, Side aSide);
This is actually really great, because these two are very similar and converting from one to the other doesn't look as difficult as having to sort out a port to use instead of a channel. The difference between the two is just that nsIEventTarget has changed to nsISerialEventTarget. Checking the git logs we can see that the relevant upstream diff that introduced this change is the following: 
$ git log -1 b2cf09ec3eada
commit b2cf09ec3eadaa988084dc71d15527ea5c89efb6
Author: Jean-Yves Avenard 
Date:   Thu Jul 2 00:26:41 2020 +0000

    Bug 1634846 - P2. Make ipc's MessageChannel works with TaskQueue, r=nika
    
    We no longer rely of having a message loop for the worker thread.
    
    Differential Revision: https://phabricator.services.mozilla.com/D80655
So after many hours of digging the fix was straightforward. I just changed the line to the following. 
Open(aParentChannel, mParentLoop->SerialEventTarget(), ipc::ChildSide);
Maybe that will take things further? We'll find out in the morning. It feels like it's been a productive day today. I've been stuck on this one issue for a couple of days now, and it's always gratifying to come to a clear conclusion.

As always, for other posts, check out my full Gecko Dev Diary.

Comments

Uncover Disqus comments

Actions

Login Email Share

Archives

View