Closed Bug 1393046 Opened 2 years ago Closed 2 years ago

Missing some JS frames

Categories

(Core :: Gecko Profiler, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox57 --- fixed

People

(Reporter: ochameau, Assigned: mstange)

References

Details

Attachments

(1 file)

Here is a profile against devtools toolbox opening.
STR:
* open firefox
* open tools via CommandOrCtrl+Shift+I (or any other way)

The first big chunk of processing in the content process will be 
resource://devtools/server/child.js loading, a frame script loaded by devtools.
Followed by some async message manager messages.
Both frame script and messages miss the JS frames

Here is an example profile:
https://perfht.ml/2vnMJFi

Note that there is some suspicious frames under EnterBaseline calls, with raw addresses:
https://perfht.ml/2v5TOij
Flags: needinfo?(mstange)
I've caught this in rr. Here's a relevant excerpt from the profile from that rr run: http://bit.ly/2xx98By
C++ symbols are missing, but there's enough information in the callstack to help tracking this down, I think. In particular, there are some js::RunScript pseudostack labels, and there are groups of three stack frames that have not been assigned to a library, i.e. jitcode. For every one of these groups-of-threes, there should be a JS frame after the first jit frame.
And the function name would probably be "require", "requireHook" or "_require".
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Flags: needinfo?(mstange)
My last recording unfortunately got destroyed. I made a new one, but this one only shows the issue for a few interpreter frames; the JIT frames are fine in this one. http://bit.ly/2wFC8um
I think what's happening here is that the JS context still has JS sampling disabled while the first bunch of JS for the devtools executes. At the moment, JS sampling on the main thread only gets enabled once the first JS interrupt callback after profiler_start fires, which is apparently too late.
Comment on attachment 8902333 [details]
Bug 1393046 - Enable JS sampling on the main thread as soon as possible after the profiler has started.

https://reviewboard.mozilla.org/r/173876/#review179438
Attachment #8902333 - Flags: review?(n.nethercote) → review+
Pushed by mstange@themasta.com:
https://hg.mozilla.org/integration/autoland/rev/ce0752c07ff6
Enable JS sampling on the main thread as soon as possible after the profiler has started. r=njn
Some ASAN devtools chunks are failing like https://treeherder.mozilla.org/logviewer.html#?job_id=127166559&repo=autoland and I can't find an obvious smoking gun so I'm seeing if backing this out will fix things.
Flags: needinfo?(mstange)
Backout by kwierso@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/0a3ef9979709
Backed out changeset ce0752c07ff6 under suspicion of causing asan failures in devtools tests a=backout CLOSED TREE
This backout didn't fix things, so feel free to reland this whenever you're ready.
Pushed by mstange@themasta.com:
https://hg.mozilla.org/integration/autoland/rev/8768af9e5e42
Enable JS sampling on the main thread as soon as possible after the profiler has started. r=njn
https://hg.mozilla.org/mozilla-central/rev/8768af9e5e42
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Flags: needinfo?(mstange)
It looks like it fixed most JS stacks but still miss the first one.
See this profile: https://perfht.ml/2exgP3a
This is with the same STR as comment 0.

In this profile slice, you can see that the first half contains no JS stack if you filter only JS.
You can see that the second half contains JS frames.
But there is JS executed in both halfs!

In this first half, if you exand on PBrowser::Msg_LoadRemoteScript,
as before you will see some calls to EnterBaseline followed with unresolved addresses.
Flags: needinfo?(mstange)
(I used artifact builds against latest tip from today)
Here is another case, which is different as it is in parent process and happening late (not in any kind of startup).
  https://perfht.ml/2eyD9cI
If you expand that tree you will see valid JS frames from react.js and a bunch of unresolved addresses.

The STR is the same, but the piece of code is harder to spot, from the overall profile, look for setCanReader and you will find it under updateChildren calls from react.
Thanks for checking. I filed bug 1397718 to take a look at the remaining issues.
Flags: needinfo?(mstange)
Duplicate of this bug: 1374375
You need to log in before you can comment on or make changes to this bug.