Closed Bug 1776694 Opened 2 years ago Closed 2 years ago

For local builds on desktop, we don't get symbols for libraries which are only loaded in child processes (plugin-container, libmozavcodec.so)

Tracking

()

Status:

RESOLVED FIXED

Milestone:

113 Branch

Tracking Flags:

Tracking

Status

firefox113

---

fixed

People

(Reporter: mstange, Assigned: canova)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fxp])

Attachments

(10 files, 1 obsolete file)

Bug 1776694 - Implement move operator for SharedLibraryInfo r?mstange! 2 years ago Julien Wajsberg [:julienw] 48 bytes, text/x-phabricator-request		Details \| Review
Bug 1776694 - Return a Result object from profiler_stream_json_for_this_process r?mstange! 2 years ago Julien Wajsberg [:julienw] 48 bytes, text/x-phabricator-request		Details \| Review
Bug 1776694 - Return the library info from the JSON generation functions r?mstange! 2 years ago Julien Wajsberg [:julienw] 48 bytes, text/x-phabricator-request		Details \| Review
WIP: fixup! Bug 1776694 - Return the library info from the JSON generation functions 2 years ago Julien Wajsberg [:julienw] 48 bytes, text/x-phabricator-request		Details \| Review
Bug 1776694 - Make GrabShutdownProfile return the additional information as well r?mstange! 2 years ago Julien Wajsberg [:julienw] 48 bytes, text/x-phabricator-request		Details \| Review
Bug 1776694 - Add a method to SharedLibraryInfo that would add all the entries from another SharedLibraryInfo instance r?mstange! 2 years ago Julien Wajsberg [:julienw] 48 bytes, text/x-phabricator-request		Details \| Review
Bug 1776694 - Implement ParamTraits for shared library and additional information structs r?mstange! 2 years ago Nazım Can Altınova [:canova][:canaltinova on phabricator] 48 bytes, text/x-phabricator-request		Details \| Review
Bug 1776694 - Transfer the profile additional information from children processes to parent r?mstange! 2 years ago Nazım Can Altınova [:canova][:canaltinova on phabricator] 48 bytes, text/x-phabricator-request		Details \| Review
Bug 1776694 - Gather all the additional information from children and return it from StartGathering r?mstange! 2 years ago Nazım Can Altınova [:canova][:canaltinova on phabricator] 48 bytes, text/x-phabricator-request		Details \| Review
Bug 1776694 - Return profile with additional info from GetProfileDataAsGzippedArrayBuffer r?mstange!,emilio 2 years ago Nazım Can Altınova [:canova][:canaltinova on phabricator] 48 bytes, text/x-phabricator-request		Details \| Review
Bug 1776694 - Use the shared libraries that's provided by getProfileDataAsGzippedArrayBuffer r?mstange! 2 years ago Nazım Can Altınova [:canova][:canaltinova on phabricator] 48 bytes, text/x-phabricator-request		Details \| Review

Markus Stange [:mstange]

Reporter

Description

•

2 years ago

Example profiles: https://share.firefox.dev/3HYUtnV , https://share.firefox.dev/3ynoWc5

Steps to reproduce:

Build Firefox locally.
Run the build and capture a profile.
Check the content process and the RDD process.

Expected results:
Every library that was compiled as part of the local build should have symbols.

Actual results:
On macOS, in the child process, there's an unsymbolicated frame near the root of the call tree in plugin-container.
On Linux, in the RDD process, the frames for libmozavcodec.so are unsymbolicated.

More generally, any library which is not loaded in the parent process doesn't have symbols.

Markus Stange [:mstange]

Reporter

Comment 1

•

2 years ago

This is because we use Services.profiler.sharedLibraries to determine which absolute paths symbolication is allowed to access. It only returns libraries that are loaded in the parent process.

https://searchfox.org/mozilla-central/rev/bf6f194694c9d1ae92847f3d4e4c15c2486f3200/devtools/client/performance-new/popup/background.jsm.js#318-336

const profileCaptureResult = await Services.profiler
  .getProfileDataAsGzippedArrayBuffer()
  .then(
    profile => ({ type: "SUCCESS", profile }),
    error => {
      console.error(error);
      return { type: "ERROR", error };
    }
  );

const profilerViewMode = getProfilerViewModeForCurrentPreset(pageContext);
const sharedLibraries = Services.profiler.sharedLibraries;
const objdirs = getObjdirPrefValue();

const { createLocalSymbolicationService } = lazy.PerfSymbolication();
const symbolicationService = createLocalSymbolicationService(
  sharedLibraries,
  objdirs
);

We should call createLocalSymbolicationService with a list of libraries which contains libraries loaded in all processes.

We could get such a list by traversing the subprofiles in profileCaptureResult. But this would mean that we would have to parse the array buffer as JSON, which would materialize the full parsed profile in the memory of the parent process, which is slow and takes up memory.

We should investigate whether we can instead get an integrated list of all shared libraries from nsIProfiler.
In other conversations we've had recently (JS source code, source maps, JIT symbols) we've tossed around the idea to return some "supplemental" information along with the profile array buffer; we could put the integrated list in that supplemental information object.

Markus Stange [:mstange]

Reporter