This bug is about what to do in CI; see bug 1720356 for what should happen when running tests locally. --- We have a [`ProfilerSymbolicator`](https://searchfox.org/mozilla-central/search?q=ProfileSymbolicator&path=&case=false®exp=false) in testing/mozbase/mozgeckoprofiler/ which we use to symbolicate profiles captured with the Gecko profiler, for example the profiles captured during browsertime pageload tests. This symbolication code is quite old and hasn't kept pace with recent improvements: - No inline callstacks - No source view - No assembly view Example: https://share.firefox.dev/4kBmPay The improvements listed above are available when symbolication is performed on profiler.firefox.com by [some JS code in symbolication.js](https://github.com/firefox-devtools/profiler/blob/eda47aef1d42c213af2bb519cc842ae252357ef7/src/profile-logic/symbolication.js). The implementation is quite a bit more complicated than what we have today in the Python code mentioned earlier. Here's what happens when you capture a profile with the Firefox UI the normal way: 1. Firefox produces an unsymbolicated JSON file, in the "gecko profile" format. 2. The JSON file is loaded into profiler.firefox.com. 3. profiler.firefox.com converts the JSON into the "processed profile" format. 4. profiler.firefox.com symbolicates the converted profile, with the help of the symbol server. To fix this bug, we need to find a way for our in-CI symbolication to share code with profiler.firefox.com. It's not practical to create a second implementation in Python of both profile format conversion and symbolication. In the profiler repo, there is a [`symbolicator-cli` script](https://github.com/firefox-devtools/profiler/blob/main/src/symbolicator-cli/index.js) which is well-suited for our purposes. It needs to be run with node, and it requires a symbolication API, such as the one that samply runs when you do `samply load profile.json`. If we can find a way to integrate this script into testing CI, it would solve this bug.
Bug 1970961 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This bug is about what to do in CI; see bug 1720356 for what should happen when running tests locally. --- We have a [`ProfilerSymbolicator`](https://searchfox.org/mozilla-central/search?q=ProfileSymbolicator&path=&case=false®exp=false) in testing/mozbase/mozgeckoprofiler/ which we use to symbolicate profiles captured with the Gecko profiler, for example the profiles captured during browsertime pageload tests. This symbolication code is quite old and hasn't kept pace with recent improvements: - No inline callstacks - No source view - No assembly view Example: https://share.firefox.dev/4kBmPay The improvements listed above are available when symbolication is performed on profiler.firefox.com by [some JS code in symbolication.js](https://github.com/firefox-devtools/profiler/blob/eda47aef1d42c213af2bb519cc842ae252357ef7/src/profile-logic/symbolication.js). The implementation is quite a bit more complicated than what we have today in the Python code mentioned earlier. Here's what happens when you capture a profile with the Firefox UI the normal way: 1. Firefox produces an unsymbolicated JSON file, in the "gecko profile" format. 2. The JSON file is loaded into profiler.firefox.com. 3. profiler.firefox.com converts the JSON into the "processed profile" format. 4. profiler.firefox.com symbolicates the converted profile, with the help of the symbol server. To fix this bug, we need to find a way for our in-CI symbolication to share code with profiler.firefox.com. It's not practical to create a second implementation in Python of both profile format conversion and symbolication. In the profiler repo, there is a [`symbolicator-cli` script](https://github.com/firefox-devtools/profiler/blob/main/src/symbolicator-cli/index.js) which is well-suited for our purposes. It needs to be run with node, and it requires a URL to a symbol server, such as the one that samply runs locally when you do `samply load profile.json`. If we can find a way to integrate this script into testing CI, it would solve this bug.
This bug is about what to do in CI; see bug 1720356 for what should happen when running tests locally. Edit 2025-07-25: This bug is now "Use `symblicator-cli` (being added in bug 1969490) for symbolicating Gecko profiles, too, not just for simpleperf profiles". Original discussion below. --- We have a [`ProfilerSymbolicator`](https://searchfox.org/mozilla-central/search?q=ProfileSymbolicator&path=&case=false®exp=false) in testing/mozbase/mozgeckoprofiler/ which we use to symbolicate profiles captured with the Gecko profiler, for example the profiles captured during browsertime pageload tests. This symbolication code is quite old and hasn't kept pace with recent improvements: - No inline callstacks - No source view - No assembly view Example: https://share.firefox.dev/4kBmPay The improvements listed above are available when symbolication is performed on profiler.firefox.com by [some JS code in symbolication.js](https://github.com/firefox-devtools/profiler/blob/eda47aef1d42c213af2bb519cc842ae252357ef7/src/profile-logic/symbolication.js). The implementation is quite a bit more complicated than what we have today in the Python code mentioned earlier. Here's what happens when you capture a profile with the Firefox UI the normal way: 1. Firefox produces an unsymbolicated JSON file, in the "gecko profile" format. 2. The JSON file is loaded into profiler.firefox.com. 3. profiler.firefox.com converts the JSON into the "processed profile" format. 4. profiler.firefox.com symbolicates the converted profile, with the help of the symbol server. To fix this bug, we need to find a way for our in-CI symbolication to share code with profiler.firefox.com. It's not practical to create a second implementation in Python of both profile format conversion and symbolication. In the profiler repo, there is a [`symbolicator-cli` script](https://github.com/firefox-devtools/profiler/blob/main/src/symbolicator-cli/index.js) which is well-suited for our purposes. It needs to be run with node, and it requires a URL to a symbol server, such as the one that samply runs locally when you do `samply load profile.json`. If we can find a way to integrate this script into testing CI, it would solve this bug.