Closed Bug 1690384 Opened 10 months ago Closed 10 months ago

Improve verbosity of error codes in loadGeckoLibsNative


(GeckoView :: General, task, P1)



(firefox88 fixed)

88 Branch
Tracking Status
firefox88 --- fixed


(Reporter: bugzilla, Assigned: bugzilla)



(Whiteboard: [geckoview:m87][geckoview:m88])


(1 file)

IMHO we don't have enough information to solve bug 1637597 without better metadata about the failure. We're just too early in browser startup to be able to troubleshoot a failure code that is, in essence, boolean.

I'm going to dive into this further and add additional context to the error code in the hope that future crash reports may give us more accurate data about the failure's causality.

We know that some GV installations (particularly but not exlcusively Focus) are
failing to load during early Gecko bootstrapping. Unfortunately
a boolean pass/fail result is not giving us sufficient information to be able to
properly troubleshoot this problem.

This patch adds mozilla::Result-based return values to XPCOMGlueLoad and
GetBootstrap in an effort to produce more actionable information about these

We include the source file, source line, and either a nsresult or, if the
failure is rooted in a dynamic linker failure, appropriate platform-specific
error information:

  • On Unix-based platforms, a UniqueFreePtr<char> containing the string from dlerror(3);
  • On Windows, the Win32 DWORD error code from GetLastError().

For non-Android platforms, I updated them to handle the new return type, but
otherwise did not make any further changes.

For Android, we include the error information in the message string that we pass
into the Java Exception that is subsequently thrown.

Whiteboard: [geckoview:m87] → [geckoview:m87][geckoview:m88]
Pushed by
Propagate error information up through XPCOMGlueLoad and GetBootstrap; r=glandium
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
See Also: → 1694625
You need to log in before you can comment on or make changes to this bug.