1811755 - Running a particular demo with the profiler leads to exponential memory use, OOM and crash

Status: RESOLVED WORKSFORME

(Core :: Gecko Profiler, defect, P2)

Description

[Mayank Bansal]

Attachment: Look at PID 4824

Go to https://www.fxhash.xyz/generative/10872
Enable the profiler (i use the "Graphics" preset)
On the demo page, click on "run"

AR: Immediate exponential memory use. Browser will OOM in a few seconds

Comment 1

[Mayank Bansal]

Attachment: Look at PID 35484

Comment 2

[Mayank Bansal]

Attachment: about:support

Comment 3

[Mayank Bansal]

I tested this bug on a build from 2021-Jan, and could repro. So this is not a recent regression.

Comment 4

[Florian Quèze [:florian]]

Comment on attachment 9313460 [details]
Look at PID 35484

This is an about:memory report showing:

7,254.94 MB (100.0%) -- explicit
├──7,073.41 MB (97.50%) ── heap-unclassified
├─────99.20 MB (01.37%) -- heap-overhead
│     ├──94.55 MB (01.30%) ── bookkeeping
│     └───4.64 MB (00.06%) ++ (3 tiny)
└─────82.33 MB (01.13%) ++ (24 tiny)

Comment 5

[Florian Quèze [:florian]]

I can reproduce, here's a profile of it: https://share.firefox.dev/3kuZ21D
I think the problem here is that the profiler allocates a buffer chunk every time Window.setTimeout is called to record the stack that created the timer.

In my case, about:memory showed:

6,802.45 MB (100.0%) -- explicit
├──6,450.99 MB (94.83%) ── heap-unclassified
├────269.64 MB (03.96%) -- heap-overhead
│    ├──256.51 MB (03.77%) ── bookkeeping
│    └───13.13 MB (00.19%) ++ (3 tiny)
└─────81.81 MB (01.20%) ++ (24 tiny)

Comment 6

[Florian Quèze [:florian]]

(In reply to Mayank Bansal from comment #0)

AR: Immediate exponential memory use. Browser will OOM in a few seconds

I can't reproduce the OOM crash, and the memory use isn't exponential: it quickly grows to 8GB (the size of profiler buffer chunks allocated when lots of setTimeout calls are made at the beginning of the demo) and then slowly shrinks as timers fire. Here's a profile where I kept the demo running for longer where half of the memory was already freed within a minute: https://share.firefox.dev/3iW5RsC

Something else that's concerning is that it seems all these profiler buffers are not freed when the profiler is stopped, only when the timers fire.

Comment 7

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

Looks like a significant issue, thanks for filing. I agree what Florian said. It looks like because of the excessive stacks that are being captured for markers. Filed Bug 1811807 for this issue specifically.

(In reply to Florian Quèze [:florian] from comment #6)

Something else that's concerning is that it seems all these profiler buffers are not freed when the profiler is stopped, only when the timers fire.

Yeah, I don't think we have a way to free all the stacks when the profiler stops. That's another reason to use our main buffer instead of these small ones.

Comment 9

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

Closing because no crashes reported for 12 weeks.