Closed Bug 1566986 Opened 5 years ago Closed 5 years ago

getSymbolTable call never returns for profiler popup's frame script

Categories

(Core :: Gecko Profiler, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla71
Tracking Status
firefox71 --- verified

People

(Reporter: dholbert, Assigned: mstange)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

STR (on my Ubuntu 19.04 laptop at least)
0. Use a fresh Firefox profile.

  1. Tools | Web Developer | Enable Profiler Toolbar Icon.
  2. Ctrl+Shift+1 to start profiling.
  3. Visit https://www.tiny.cloud/docs/demo/full-featured/
  4. Ctrl+Shift+2 to capture the profile.

ACTUAL RESULTS:
The symbols never finish loading, so I'm unable to publish the profile. In particular:

  • The green "Publish" button has no effect when I click it.
  • There's a gray bar at the top saying Waiting for symbol tables for libaom.so.0...
  • My Browser Console gets the following error logged to it:

Error: The library libaom.so.0 BFF23E907B6779E5B133D5D479F1A0C00 is not in the Services.profiler.sharedLibraries list, so the local path for it is not known and symbols for it can not be obtained. This usually happens if a content process uses a library that's not used in the parent process - Services.profiler.sharedLibraries only knows about libraries in the parent process. background.jsm:73:11

EXPECTED RESULTS:

  • The "Waiting" message should go away once we realize that symbols aren't coming.
  • I should be able to publish the profile in its mostly-symbolicated state at that point.

Note: I'm able to work around this by using the add-on from https://profiler.firefox.com/ instead of the built-in profiling support.

Oh! That sounds like the built-in profiling support is just not propagating errors to the web page properly.

Update: actually maybe this doesn't block publishing after all. The Publish button was definitely broken for me earlier on, when I was trying (perhaps in part because I mashed the "Publish" button too early and that got us into an unexpected state)... But, just now, I went back to the Firefox instance that I used to validate my STR when filing this bug, and I noticed that the "Waiting" bar is indeed still there, but "Publish" also did work (and gave me this profile: https://perfht.ml/2Yb0vgM )

In this case I didn't try clicking "Publish" until ~20min after having performed the STR, so I don't know how long was required before the Publish button started working, but it did eventually work.

Anyway: there might still be something broken about the activation of that button based on my earlier experience... And in any case the perma-"Waiting..." bar seems like it needs fixing.

Greg, any thoughts please?

Flags: needinfo?(gtatum)
Priority: -- → P2

The getSymbolTable reply is not being sent through the pop-up. https://searchfox.org/mozilla-central/rev/4fbcfe6fecf75d7b828fbebda79a31385f7eab5f/devtools/client/performance-new/frame-script.js#58-66

The profile is waiting here forever: https://github.com/firefox-devtools/profiler/blob/master/src/profile-logic/symbol-store.js#L348-L350

I wasn't able to reproduce the issue on the devtools path, which uses the same frame script injection, so something is definitely wrong with the popup path. Thanks for the bug report :dholbert!

I could not reproduce the Publish button not working, which sounds like it's a separate issue.

Flags: needinfo?(gtatum)
Blocks: 1566920
Summary: Unable to publish profiles, with perma-stuck gray bar "Waiting for symbol tables for libaom.so.0..." and browser console error message "Error: The library [...] is not in the Services.profiler.sharedLibraries list" → getSymbolTable call never returns for profiler popup's frame script

Also, this regression would be perfect for setting up our tests for the popup.

Oh, and one other thing. I was able to reproduce this on Mac with my local debug build. I couldn't reproduce it on Nightly, as I'm assuming I have all the symbols from the symbol server.

Blocks: 1572786

Found the bug: When getSymbols throws an exception, the caller doesn't catch it because it expects errors to be propagated with a rejected promise and not with a synchronous exception.
That's a reasonable expectation, we should make getSymbols an async function.

Assignee: nobody → mstange
Status: NEW → ASSIGNED
Pushed by mstange@themasta.com: https://hg.mozilla.org/integration/autoland/rev/4fd6313ecc90 Make getSymbols an async function so that callers always get a promise and never a synchronous exception. r=gregtatum
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

Confirmed errors with 70.0a1 (2019-07-17) on Windows 10.
Verified with 71.0a1 (2019-09-04) on Windows 10, macOS 10.13, Ubuntu 18.04 and current nighlty 72.0a1 on Windows 10.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: