1763176 - The memory tracks are missing on startup profiles

Status: RESOLVED FIXED

(Core :: Gecko Profiler, defect, P1)

Description

[Florian Quèze [:florian]]

Here's a startup profile captured today on my local build: https://share.firefox.dev/3DK9rMk

It doesn't have the memory tracks.

A random non-startup profile captured using the same build has memory tracks: https://share.firefox.dev/3j95AiI

Random guess: could this be a regression from when we merged the base profiler tracks?

The two profiles above are from my M1 macbook pro, I haven't verified if the bug reproduces on other platforms.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:gerald, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Sorry I didn't look at this earlier.

This was actually triggered by added the per-process CPU counter, but the root cause is that the counter-streaming code cannot handle two counters next to each other, which now happens because the sampler loop samples both counters (by chance process cpu then memory) together.

Comment 3

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

I'll register bug 1744670 as "regressed by" bug, because even though that's not where the root cause is, that's the point where this bug started happening (so Firefox 98), and when it should have been caught.

Comment 4

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Workaround if needed: Note that it can be avoided by manually turning off the per-process CPU feature.

Comment 5

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Attachment: Bug 1763176 - Don't move to the next entry after streaming a counter, as it would skip an immediately-adjacent counter - r?canaltinova

If the sampler records more than one counter (e.g.: memory and per-process CPU), both counters could appear right next to each other in the buffer.
But then the current streaming code goes something like this:

1. Read entry
2. If entry is a counter, go to the next entry (which should be a timestamp) and output the full counter.
3. Go to the next entry.
   4: Return to step 1 (until there are no more entries).

The problem is this unconditional 3rd step:
If we've just read a counter at step 2, we're located at the entry past that counter's data, which could be the start of the next counter, that the 3rd step now effectively skips!

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e81e897d7209
Don't move to the next entry after streaming a counter, as it would skip an immediately-adjacent counter - r=canaltinova

Comment 7

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/e81e897d7209