When you capture a profile in the browser the normal way, the browser opens the profiler tab, loads the profile into it, and supplies symbolication information. However, you can also capture profiles in other ways, and save them as a file, without symbolication. (Examples: calling `Services.profiler.dumpProfileToFileAsync` on the error console, `MOZ_SHUTDOWN_PROFILE=profile.json`, browsertime profiling...) Then, if you load those files in the profiler, there may not be any symbols, especially if the profile was captured from a local Firefox build. This is because for manually opened tabs, there was no symbolication connection to the browser. However, once symbolication happens via the WebChannel (bug 1625309), there will always be a connection to the browser, in all profiler tabs. We can make this use case work with the WebChannel. Steps to reproduce: 1. Make a local Firefox build. 2. Start the build with `MOZ_PROFILER_STARTUP=1 MOZ_PROFILER_SHUTDOWN=profile.json ./mach run` , let it run for a few seconds, and quit it again. 3. Run the same build again, normally. 4. Open a profiler.firefox.com tab. 5. Drag the profile.json file from step 2 into the profiler tab. Expected results: The profile should load and then get symbols for libxul. Actual results: The profile loads but has no symbols for libxul. --- Non-goals for this bug: - Loading a profile in a Firefox build that's different from the one that the profile was captured from. - Loading a profile that was captured from Android. These will not get symbols.
Bug 1726281 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.
When you capture a profile in the browser the normal way, the browser opens the profiler tab, loads the profile into it, and supplies symbolication information. However, you can also capture profiles in other ways, and save them as a file, without symbolication. (Examples: calling `Services.profiler.dumpProfileToFileAsync` on the error console, `MOZ_SHUTDOWN_PROFILE=profile.json`, browsertime profiling...) Then, if you load those files in the profiler, there may not be any symbols, especially if the profile was captured from a local Firefox build. This is because for manually opened tabs, there was no symbolication connection to the browser. However, once symbolication happens via the WebChannel (bug 1625309), there will always be a connection to the browser, in all profiler tabs. We can make this use case work with the WebChannel. Steps to reproduce: 1. Make a local Firefox build. 2. Start the build with `MOZ_PROFILER_STARTUP=1 MOZ_PROFILER_SHUTDOWN=profile.json ./mach run` , let it run for a few seconds, and quit it again. 3. Run the same build again, normally. 4. Open a profiler.firefox.com tab in that build. 5. Drag the profile.json file from step 2 into the profiler tab. Expected results: The profile should load and then get symbols for libxul. Actual results: The profile loads but has no symbols for libxul. --- Non-goals for this bug: - Loading a profile in a Firefox build that's different from the one that the profile was captured from. - Loading a profile that was captured from Android. These will not get symbols.
When you capture a profile in the browser the normal way, the browser opens the profiler tab, loads the profile into it, and supplies symbolication information. However, you can also capture profiles in other ways, and save them as a file, without symbolication. (Examples: calling `Services.profiler.dumpProfileToFileAsync` on the error console, `MOZ_SHUTDOWN_PROFILE=profile.json`, browsertime profiling...) Then, if you load those files in the profiler, there may not be any symbols, especially if the profile was captured from a local Firefox build. This is because for manually opened tabs, there was no symbolication connection to the browser. However, once symbolication happens via the WebChannel (bug 1625309), there will always be a connection to the browser, in all profiler tabs. We can make this use case work with the WebChannel. Steps to reproduce: 1. Make a local Firefox build. 2. Start the build with `MOZ_PROFILER_STARTUP=1 MOZ_PROFILER_SHUTDOWN=profile.json ./mach run` , let it run for a few seconds, and quit it again. 3. Run the same build again, normally. 4. Open a profiler.firefox.com tab in that build. 5. Drag the profile.json file from step 2 into the profiler tab. Expected results: The profile should load and then get symbols for libxul. Actual results: The profile loads but has no symbols for libxul. --- Non-goals for this bug: - Loading a profile in a Firefox build that's different from the one that the profile was captured from. - Loading a profile that was captured from Android. These will not get symbols.
When you capture a profile in the browser the normal way, the browser opens the profiler tab, loads the profile into it, and supplies symbolication information. However, you can also capture profiles in other ways, and save them as a file, without symbolication. (Examples: calling `Services.profiler.dumpProfileToFileAsync` on the error console, `MOZ_SHUTDOWN_PROFILE=profile.json`, browsertime profiling...) Then, if you load those files in the profiler, there may not be any symbols, especially if the profile was captured from a local Firefox build. This is because for manually opened tabs, there was no symbolication connection to the browser. However, once symbolication happens via the WebChannel (bug 1625309), there will always be a connection to the browser, in all profiler tabs. We can use the WebChannel to make this use case work. Steps to reproduce: 1. Make a local Firefox build. 2. Start the build with `MOZ_PROFILER_STARTUP=1 MOZ_PROFILER_SHUTDOWN=profile.json ./mach run` , let it run for a few seconds, and quit it again. 3. Run the same build again, normally. 4. Open a profiler.firefox.com tab in that build. 5. Drag the profile.json file from step 2 into the profiler tab. Expected results: The profile should load and then get symbols for libxul. Actual results: The profile loads but has no symbols for libxul. --- Non-goals for this bug: - Loading a profile in a Firefox build that's different from the one that the profile was captured from. - Loading a profile that was captured from Android. These will not get symbols.