For local builds on desktop, we don't get symbols for libraries which are only loaded in child processes (plugin-container, libmozavcodec.so)
Categories
(Core :: Gecko Profiler, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox113 | --- | fixed |
People
(Reporter: mstange, Assigned: canova)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fxp])
Attachments
(10 files, 1 obsolete file)
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
Bug 1776694 - Implement ParamTraits for shared library and additional information structs r?mstange!
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details |
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.
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.
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.
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 2•2 years ago
|
||
Julien, I think this bug would be a good place to start building out the ProfileWithInfo
infrastructure: We need an nsIProfiler
API which returns the profile itself as an array buffer (gzipped or not, I don't know), and along with it some JS-consumable extra info which the privileged profiler JS can look at without having to JSON-parse the entire profile. In this bug, the extra info would just be the list of shared libraries. And this extra info should be accumulated from all processes. The other processes would send it up to the parent process in the same IPC call as they send the profile JSON itself, so this IPC call will need to get a new argument with an IPC-serializable type (e.g. ProfileExtraInfo
).
Would you like to take a stab at this?
Once we have this infrastructure, it'll also be used for the implementation of the JS source view, source maps, and JIT profiling.
Reporter | ||
Comment 3•2 years ago
|
||
We can leave the Android case out of the initial implementation. When profiling Android, we currently parse the entire profile into a JS object anyway, which is covered by bug 1581963.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 5•2 years ago
|
||
Comment 6•2 years ago
|
||
Depends on D170500
Comment 7•2 years ago
|
||
Depends on D170501
Updated•2 years ago
|
Comment 8•2 years ago
|
||
Depends on D170502
Comment 9•2 years ago
|
||
Depends on D170782
Comment 10•2 years ago
|
||
Depends on D170783
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 11•2 years ago
|
||
Depends on D170922
Assignee | ||
Comment 12•2 years ago
|
||
Depends on D172552
Assignee | ||
Comment 13•2 years ago
|
||
Depends on D172553
Assignee | ||
Comment 14•2 years ago
|
||
Depends on D172554
Assignee | ||
Comment 15•2 years ago
|
||
Depends on D172555
Comment 16•2 years ago
|
||
Comment 17•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0ce9f03d3142
https://hg.mozilla.org/mozilla-central/rev/1d4524a65bbf
https://hg.mozilla.org/mozilla-central/rev/61a720cb90f1
https://hg.mozilla.org/mozilla-central/rev/4fe9056b071b
https://hg.mozilla.org/mozilla-central/rev/4791ee289eb6
https://hg.mozilla.org/mozilla-central/rev/0527899014b2
https://hg.mozilla.org/mozilla-central/rev/c80a01cb9bc5
https://hg.mozilla.org/mozilla-central/rev/700a30a5a8de
https://hg.mozilla.org/mozilla-central/rev/479ecea2cb14
https://hg.mozilla.org/mozilla-central/rev/3323b6f7c34f
Description
•