List items
Items from the current list are shown below.
Blog
13 Feb 2024 : Day 155 #
This morning the build I started yesterday has completed successfully. Now to test it.
You'll recall that the purpose of the build was to add some debugging output to find out what's going on with the Window Actors and the LoginManager actor in particular. Is it being registered? Are others being registered? Are others being requested? Every time one of these events occurs we should get some appropriate debug output so that we know.
To actually see the output we'll need to activate the BrowsingContext log output, like this:
This... looks suspicious to me. I'm not entirely convinced that the logging I've added is working, particularly for the printf() output I added to the JSActorService class.
I don't want to have to make another build, but thankfully we can check this using the debugger.
The obvious thing to do now is to check the same thing using ESR 78. So let's do that.
This is enlightening. It means that this is an iceberg moment: the error from LoginManager is exposing a much more serious problem under the surface. Honestly, I'm puzzled as to why this hasn't caused more breakages of other elements of the browser user interface.
The next step is to look at the backtrace and find out why the same code isn't executing in ESR 91. It's not the best backtrace to be honest because it's backstopped by the interpreter, but it at least gives us something to work with.
So back to ESR 91:
The backtrace gets lost when it hits JavaScript, but it looks like the JavaScript action is happen in the ActorManagerParent.jsm file. So back to ESR 78, and I've added a couple of extra debug prints to the ActorManagerParent.jsm file:
Time for a break, but when I get back I'll look into this further.
[...]
Back to it. So the question I need to answer now is "where in ESR 78 are the actors getting registered?" There are two clear candidates. The first is BrowserGlue.jsm. This includes code to get the ActorManagerParent:
I should be able to check this pretty straightforwardly. If I comment out the code in EmbedLiteGlobalHelper.js related to the actors like this:
Once again, this feels like progress, but an answer for this question will have to wait until tomorrow.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
You'll recall that the purpose of the build was to add some debugging output to find out what's going on with the Window Actors and the LoginManager actor in particular. Is it being registered? Are others being registered? Are others being requested? Every time one of these events occurs we should get some appropriate debug output so that we know.
To actually see the output we'll need to activate the BrowsingContext log output, like this:
$ MOZ_LOG="BrowsingContext:5" sailfish-browser
[D] unknown:0 - Using Wayland-EGL
library "libutils.so" not found
library "libcutils.so" not found
library "libhardware.so" not found
library "android.hardware.graphics.mapper@2.0.so" not found
library "android.hardware.graphics.mapper@2.1.so" not found
library "android.hardware.graphics.mapper@3.0.so" not found
library "android.hardware.graphics.mapper@4.0.so" not found
library "libc++.so" not found
library "libhidlbase.so" not found
library "libgralloctypes.so" not found
library "android.hardware.graphics.common@1.2.so" not found
library "libion.so" not found
library "libz.so" not found
library "libhidlmemory.so" not found
library "android.hidl.memory@1.0.so" not found
library "vendor.qti.qspmhal@1.0.so" not found
greHome from GRE_HOME:/usr/bin
libxul.so is not found, in /usr/bin/libxul.so
Created LOG for EmbedLiteTrace
[D] onCompleted:105 - ViewPlaceholder requires a SilicaFlickable parent
Created LOG for EmbedLite
Created LOG for EmbedPrefs
Created LOG for EmbedLiteLayerManager
[Parent 4610: Unnamed thread 7908002670]: D/BrowsingContext Creating 0x00000003
in Parent
[Parent 4610: Unnamed thread 7908002670]: D/BrowsingContext Parent: Connecting
0x00000003 to 0x00000000 (private=0, remote=0, fission=0, oa=)
ACTOR: Getting LoginManager
[Parent 4610: Unnamed thread 7908002670]: D/BrowsingContext ACTOR: GetActor:
JavaScript error: resource://gre/modules/LoginManagerChild.jsm, line 542:
NotFoundError: WindowGlobalChild.getActor: No such JSWindowActor
'LoginManager'
ACTOR: Getting LoginManager
[Parent 4610: Unnamed thread 7908002670]: D/BrowsingContext ACTOR: GetActor:
JavaScript error: resource://gre/modules/LoginManagerChild.jsm, line 542:
NotFoundError: WindowGlobalChild.getActor: No such JSWindowActor
'LoginManager'
[Parent 4610: Unnamed thread 7908002670]: D/BrowsingContext Parent: Detaching
0x00000003 from 0x00000000
Call EmbedLiteApp::StopChildThread()
Redirecting call to abort() to mozalloc_abort
It's a little hard to tell, but there are actually only a couple of relevant lines of output in there. Let's clean that up a bit:
$ MOZ_LOG="BrowsingContext:5" sailfish-browser 2>&1 | grep -E "ACTOR:|error"
ACTOR: Getting LoginManager
[Parent 4720: Unnamed thread 7668002670]: D/BrowsingContext ACTOR: GetActor:
JavaScript error: resource://gre/modules/LoginManagerChild.jsm, line 542:
NotFoundError: WindowGlobalChild.getActor: No such JSWindowActor
'LoginManager'
ACTOR: Getting LoginManager
[Parent 4720: Unnamed thread 7668002670]: D/BrowsingContext ACTOR: GetActor:
JavaScript error: resource://gre/modules/LoginManagerChild.jsm, line 542:
NotFoundError: WindowGlobalChild.getActor: No such JSWindowActor
'LoginManager'
So what we have is an access to GetActor() but without any apparent registrations for this or any other actors.This... looks suspicious to me. I'm not entirely convinced that the logging I've added is working, particularly for the printf() output I added to the JSActorService class.
I don't want to have to make another build, but thankfully we can check this using the debugger.
$ MOZ_LOG="BrowsingContext:5" gdb sailfish-browser
GNU gdb (GDB) Mer (8.2.1+git9)
[...]
(gdb) b JSActorService::RegisterWindowActor
Function "JSActorService::RegisterWindowActor" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (JSActorService::RegisterWindowActor) pending.
(gdb) b JSActorService::UnregisterWindowActor
Function "JSActorService::UnregisterWindowActor" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (JSActorService::UnregisterWindowActor) pending.
(gdb) b JSActorService::RegisterProcessActor
Function "JSActorService::RegisterProcessActor" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 3 (JSActorService::RegisterProcessActor) pending.
(gdb) b JSActorService::UnregisterProcessActor
Function "JSActorService::UnregisterProcessActor" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 4 (JSActorService::UnregisterProcessActor) pending.
(gdb) r
[...]
ACTOR: Getting LoginManager
[Parent 8108: Unnamed thread 7fc0002670]: D/BrowsingContext ACTOR: GetActor:
JavaScript error: resource://gre/modules/LoginManagerChild.jsm, line 542:
NotFoundError: WindowGlobalChild.getActor: No such JSWindowActor
'LoginManager'
[...]
ACTOR: Getting LoginManager
[Parent 8108: Unnamed thread 7fc0002670]: D/BrowsingContext ACTOR: GetActor:
JavaScript error: resource://gre/modules/LoginManagerChild.jsm, line 542:
NotFoundError: WindowGlobalChild.getActor: No such JSWindowActor
'LoginManager'
[Parent 8108: Unnamed thread 7fc0002670]: D/BrowsingContext Parent: Detaching
0x00000003 from 0x00000000
Call EmbedLiteApp::StopChildThread()
Redirecting call to abort() to mozalloc_abort
[...]
(gdb) info break
Num Type Disp Enb What
1 breakpoint keep y in mozilla::dom::JSActorService::RegisterWindowActor
(nsTSubstring<char> const&, mozilla::dom::
WindowActorOptions const&, mozilla::ErrorResult&)
at dom/ipc/jsactor/JSActorService.cpp:60
2 breakpoint keep y in mozilla::dom::JSActorService::UnregisterWindowActor
(nsTSubstring<char> const&)
at dom/ipc/jsactor/JSActorService.cpp:109
3 breakpoint keep y in mozilla::dom::JSActorService::RegisterProcessActor
(nsTSubstring<char> const&, mozilla::dom::
ProcessActorOptions const&, mozilla::ErrorResult&)
at dom/ipc/jsactor/JSActorService.cpp:231
4 breakpoint keep y in mozilla::dom::JSActorService::UnregisterProcessActor
(nsTSubstring<char> const&)
at dom/ipc/jsactor/JSActorService.cpp:275
(gdb)
Even though the breakpoints found places to attach, there are no hits. It really does look like the entire actor functionality is missing, which may or may not be intended.The obvious thing to do now is to check the same thing using ESR 78. So let's do that.
$ gdb sailfish-browser
GNU gdb (GDB) Mer (8.2.1+git9)
[...]
(gdb) b JSActorService::RegisterWindowActor
Function "JSActorService::RegisterWindowActor" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (JSActorService::RegisterWindowActor) pending.
(gdb) b JSActorService::UnregisterWindowActor
Function "JSActorService::UnregisterWindowActor" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (JSActorService::UnregisterWindowActor) pending.
(gdb) b JSActorService::RegisterProcessActor
Function "JSActorService::RegisterProcessActor" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 3 (JSActorService::RegisterProcessActor) pending.
(gdb) b JSActorService::UnregisterProcessActor
Function "JSActorService::UnregisterProcessActor" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 4 (JSActorService::UnregisterProcessActor) pending.
(gdb) r
[...]
Thread 10 "GeckoWorkerThre" hit Breakpoint 1, mozilla::dom::JSActorService::
RegisterWindowActor (this=this@entry=0x7f80480850, aName=..., aOptions=...,
aRv=...) at dom/ipc/JSActorService.cpp:51
51 ErrorResult& aRv) {
(gdb) handle SIGPIPE nostop
Signal Stop Print Pass to program Description
SIGPIPE No Yes Yes Broken pipe
(gdb) p aName
$1 = (const nsACString &) @0x7fa69e3d80: {<mozilla::detail::nsTStringRepr
<char>> = {mData = 0x7fa69e3d94 "AboutHttpsOnlyError", mLength = 19,
mDataFlags = (mozilla::detail::StringDataFlags::TERMINATED |
mozilla::detail::StringDataFlags::INLINE),
mClassFlags = mozilla::detail::StringClassFlags::INLINE},
static kMaxCapacity = 2147483637}
(gdb) p aName.mData
$2 = (mozilla::detail::nsTStringRepr<char>::char_type *) 0x7fa69e3d94
"AboutHttpsOnlyError"
(gdb) c
Continuing.
Thread 10 "GeckoWorkerThre" hit Breakpoint 1, mozilla::dom::JSActorService::
RegisterWindowActor (this=this@entry=0x7f80480850, aName=..., aOptions=...,
aRv=...) at dom/ipc/JSActorService.cpp:51
51 ErrorResult& aRv) {
(gdb) p aName.mData
$3 = (mozilla::detail::nsTStringRepr<char>::char_type *) 0x7fa69e3d94
"AudioPlayback"
(gdb) c
Continuing.
Thread 10 "GeckoWorkerThre" hit Breakpoint 1, mozilla::dom::JSActorService::
RegisterWindowActor (this=this@entry=0x7f80480850, aName=..., aOptions=...,
aRv=...) at dom/ipc/JSActorService.cpp:51
51 ErrorResult& aRv) {
(gdb) p aName.mData
$4 = (mozilla::detail::nsTStringRepr<char>::char_type *) 0x7fa69e3d94
"AutoComplete"
(gdb) c
[...]
There are dozens more of them. But also, crucially, this one:
Thread 10 "GeckoWorkerThre" hit Breakpoint 1, mozilla::dom::JSActorService:: RegisterWindowActor (this=this@entry=0x7f80480850, aName=..., aOptions=..., aRv=...) at dom/ipc/JSActorService.cpp:51 51 ErrorResult& aRv) { (gdb) p aName.mData $17 = (mozilla::detail::nsTStringRepr<char>::char_type *) 0x7fa69e3a84 "LoginManager" (gdb) bt #0 mozilla::dom::JSActorService::RegisterWindowActor (this=this@entry=0x7f80480850, aName=..., aOptions=..., aRv=...) at dom/ipc/JSActorService.cpp:51 #1 0x0000007fba9881b0 in mozilla::dom::ChromeUtils::RegisterWindowActor (aGlobal=..., aName=..., aOptions=..., aRv=...) at dom/base/ChromeUtils.cpp:1243 #2 0x0000007fbae8b4f4 in mozilla::dom::ChromeUtils_Binding::registerWindowActor (cx_=<optimized out>, argc=<optimized out>, vp=0x7fa69e3b00) at ChromeUtilsBinding.cpp:4263 #3 0x0000007f00460260 in ?? () #4 0x0000007fbcb1ba80 in Interpret (cx=0x7fa69e3ad0, state=...) at js/src/vm/Activation.h:541 #5 0x0000007fbcb1ba80 in Interpret (cx=0x7f802270c0, state=...) at js/src/vm/Activation.h:541 #6 0x0000000000000000 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)
Eventually it gets through them all and the page loads. None of the other breakpoints get hit, so there don't appear to be any deregistrations.This is enlightening. It means that this is an iceberg moment: the error from LoginManager is exposing a much more serious problem under the surface. Honestly, I'm puzzled as to why this hasn't caused more breakages of other elements of the browser user interface.
The next step is to look at the backtrace and find out why the same code isn't executing in ESR 91. It's not the best backtrace to be honest because it's backstopped by the interpreter, but it at least gives us something to work with.
So back to ESR 91:
(gdb) b ChromeUtils::RegisterWindowActor Breakpoint 5 at 0x7ff2c9a0d8: file dom/base/ChromeUtils.cpp, line 1350. (gdb) b ChromeUtils_Binding::registerWindowActor Breakpoint 6 at 0x7ff31bf858: file ChromeUtilsBinding.cpp, line 5237. (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/bin/sailfish-browser [...]No hits.
The backtrace gets lost when it hits JavaScript, but it looks like the JavaScript action is happen in the ActorManagerParent.jsm file. So back to ESR 78, and I've added a couple of extra debug prints to the ActorManagerParent.jsm file:
addJSProcessActors(actors) {
dump("ACTOR: addJSProcessActors\n");
this._addActors(actors, "JSProcessActor");
},
addJSWindowActors(actors) {
dump("ACTOR: addJSWindowActors\n");
this._addActors(actors, "JSWindowActor");
},
And there's an immediate hit:
$ EMBED_CONSOLE=1 sailfish-browser [D] unknown:0 - Using Wayland-EGL library "libGLESv2_adreno.so" not found library "eglSubDriverAndroid.so" not found greHome from GRE_HOME:/usr/bin libxul.so is not found, in /usr/bin/libxul.so Created LOG for EmbedLiteTrace [D] onCompleted:105 - ViewPlaceholder requires a SilicaFlickable parent Created LOG for EmbedLite JSComp: EmbedLiteConsoleListener.js loaded JSComp: ContentPermissionManager.js loaded JSComp: EmbedLiteChromeManager.js loaded JSComp: EmbedLiteErrorPageHandler.js loaded JSComp: EmbedLiteFaviconService.js loaded ACTOR: addJSProcessActors ACTOR: addJSWindowActors JSComp: EmbedLiteGlobalHelper.js loaded EmbedLiteGlobalHelper app-startup [..]And for a bit more clarity:
$ sailfish-browser 2>&1 | grep "ACTOR:" ACTOR: addJSProcessActors ACTOR: addJSWindowActorsI've copied those same debug lines over to the ESR 91 code to see if the same methods are being called there.
$ EMBED_CONSOLE=1 sailfish-browser [D] unknown:0 - Using Wayland-EGL library "libutils.so" not found library "libcutils.so" not found library "libhardware.so" not found library "android.hardware.graphics.mapper@2.0.so" not found library "android.hardware.graphics.mapper@2.1.so" not found library "android.hardware.graphics.mapper@3.0.so" not found library "android.hardware.graphics.mapper@4.0.so" not found library "libc++.so" not found library "libhidlbase.so" not found library "libgralloctypes.so" not found library "android.hardware.graphics.common@1.2.so" not found library "libion.so" not found library "libz.so" not found library "libhidlmemory.so" not found library "android.hidl.memory@1.0.so" not found library "vendor.qti.qspmhal@1.0.so" not found greHome from GRE_HOME:/usr/bin libxul.so is not found, in /usr/bin/libxul.so Created LOG for EmbedLiteTrace [D] onCompleted:105 - ViewPlaceholder requires a SilicaFlickable parent Created LOG for EmbedLite JSComp: EmbedLiteConsoleListener.js loaded JSComp: ContentPermissionManager.js loaded JSComp: EmbedLiteChromeManager.js loaded JSComp: EmbedLiteErrorPageHandler.js loaded JSComp: EmbedLiteFaviconService.js loaded JSComp: EmbedLiteGlobalHelper.js loaded EmbedLiteGlobalHelper app-startup [...]Nothing that I can see, but just to be certain:
$ sailfish-browser 2>&1 | grep "ACTOR:" ACTOR: Getting LoginManager ACTOR: Getting LoginManagerSo somewhere between EmbedLiteFaviconService.js being loaded and EmbedLiteGlobalHelper.js being loaded the actors are registered on ESR 78, but that's not happening on ESR 91.
Time for a break, but when I get back I'll look into this further.
[...]
Back to it. So the question I need to answer now is "where in ESR 78 are the actors getting registered?" There are two clear candidates. The first is BrowserGlue.jsm. This includes code to get the ActorManagerParent:
ChromeUtils.defineModuleGetter( this, "ActorManagerParent", "resource://gre/modules/ActorManagerParent.jsm" );It even adds some actors of its own during initialisation:
// initialization (called on application startup)
_init: function BG__init() {
[...]
ActorManagerParent.addJSProcessActors(JSPROCESSACTORS);
ActorManagerParent.addJSWindowActors(JSWINDOWACTORS);
ActorManagerParent.addLegacyActors(LEGACY_ACTORS);
ActorManagerParent.flush();
[...]
},
Another, potentially more promising candidate, is EmbedLiteGlobalHelper.js. It's more promising for multiple reasons. First, it's part of embedlite-components, which means it's intended for use with sailfish-browser. Second, something in the back of my mind tells me sailfish-browser uses its own version of the browser glue. Third, and perhaps most compelling, the debug output messages come straight before EmbedLiteGlobalHelper.js is claiming to be initialised, which would fit with the the actor initialisation being part of the initialisation of EmbedLiteGlobalHelper.js.I should be able to check this pretty straightforwardly. If I comment out the code in EmbedLiteGlobalHelper.js related to the actors like this:
//ChromeUtils.defineModuleGetter(
// this,
// "ActorManagerParent",
// "resource://gre/modules/ActorManagerParent.jsm"
//);
Services.scriptloader.loadSubScript("chrome://embedlite/content/Logger.js");
// Common helper service
function EmbedLiteGlobalHelper()
{
//ActorManagerParent.flush();
[...]
Then the errors received start to look very similar to those for ESR 91:
$ sailfish-browser
[D] unknown:0 - Using Wayland-EGL
library "libGLESv2_adreno.so" not found
library "eglSubDriverAndroid.so" not found
greHome from GRE_HOME:/usr/bin
libxul.so is not found, in /usr/bin/libxul.so
Created LOG for EmbedLiteTrace
[D] onCompleted:105 - ViewPlaceholder requires a SilicaFlickable parent
Created LOG for EmbedLite
Created LOG for EmbedPrefs
Created LOG for EmbedLiteLayerManager
JavaScript error: resource://gre/modules/LoginManagerChild.jsm, line 442:
NotSupportedError: WindowGlobalChild.getActor: Could not get
JSWindowActorProtocol: LoginManager is not registered
To double-check, we can run sailfish-browser using the debugger with breakpoints on the relevant methods like this:
$ gdb sailfish-browser GNU gdb (GDB) Mer (8.2.1+git9) [...] (gdb) b JSActorService::RegisterWindowActor Function "JSActorService::RegisterWindowActor" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (JSActorService::RegisterWindowActor) pending. (gdb) b JSActorService::UnregisterWindowActor Function "JSActorService::UnregisterWindowActor" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 2 (JSActorService::UnregisterWindowActor) pending. (gdb) b JSActorService::RegisterProcessActor Function "JSActorService::RegisterProcessActor" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 3 (JSActorService::RegisterProcessActor) pending. (gdb) b JSActorService::UnregisterProcessActor Function "JSActorService::UnregisterProcessActor" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 4 (JSActorService::UnregisterProcessActor) pending. (gdb) r [...]No hits. So, in conclusion it seems that EmbedLiteGlobalHelper.js isn't being initialised on ESR 91. The task now is to find out why.
Once again, this feels like progress, but an answer for this question will have to wait until tomorrow.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
Comments
Uncover Disqus comments