Gigabytes of heap unclassified in main process
Categories
(Firefox :: Untriaged, defect)
Tracking
()
People
(Reporter: likalex3, Unassigned)
References
Details
(Whiteboard: [MemShrink:P3])
Attachments
(3 files, 1 obsolete file)
Comment 1•7 years ago
|
||
Comment hidden (metoo) |
Comment 6•7 years ago
|
||
Comment 7•7 years ago
|
||
Reporter | ||
Comment 10•7 years ago
|
||
Comment 11•7 years ago
|
||
Updated•7 years ago
|
Comment 12•7 years ago
|
||
Comment 13•7 years ago
|
||
Updated•7 years ago
|
Updated•7 years ago
|
Comment 14•7 years ago
|
||
Updated•7 years ago
|
Updated•7 years ago
|
Comment 15•7 years ago
|
||
Comment 17•7 years ago
|
||
Updated•7 years ago
|
Comment 18•7 years ago
|
||
Comment 19•6 years ago
|
||
Comment 20•6 years ago
|
||
Comment 21•5 years ago
|
||
While I can't speak for the original poster, I have seen this issue for over a year and have had to sideline Firefox support and use of Firefox Developer Edition of my companies Single Page Application.
To kick this ticket back off, some details that I can provide about the application are:
- Uses WebSocket
- Uses WebGL (via TensorFlowJS)
- Uses React / Redux (latest versions)
Symptoms:
- Open a tab to above app
- Refresh tab a few times
- Memory slowly grows with each refresh
- On Ubuntu Linux, the eventual high memory usage crashes the entire computer to the point where I have to do a hard reset
I would be happy to try the debugging steps and get this resolved or at least shed some light on whats happening.
Comment 22•5 years ago
|
||
Given that Cameron M seems to have a reliable way of reproducing this, is there a way we can get him an instrumented build to help us determine what this heap unclassified stuff is? Do we have any recent DMD builds around that he could use?
Comment 23•5 years ago
|
||
I think Nightly builds are all DMD now, so it is just a matter of passing the right argument when running it.
Comment 24•5 years ago
|
||
Also, we do have some frequent intermittent leaks on TreeHerder involving websockets, so maybe that's related...
Comment 25•5 years ago
|
||
Is Firefox Developer Edition similar to a Nightly build?
Comment 26•5 years ago
|
||
Hmm I guess I'm not sure how the symbolizing works in that case.
Comment 27•5 years ago
|
||
Eric, is there some easy way for a user to use DMD if they are experiencing issues, or is that not practical? Thanks.
Comment 28•5 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #27)
Eric, is there some easy way for a user to use DMD if they are experiencing issues, or is that not practical? Thanks.
devedition is roughly beta but with a darker theme and a separate profile, it doesn't have DMD as an option. You'd need to run Nightly. If you're on Ubuntu this is probably the easiest way to do that programmatically:
- Install nightly and run it with DMD enabled
# setup a temporary environment for testing
cd /tmp
mkdir repro && cd repro
virtualenv test-nightly && source test-nightly/bin/activate
# Use helpers to download and install a nightly
pip install mozdownload mozinstall mozrunner
mozdownload -t daily && mozinstall *.bz2
# Run nightly with DMD enabled in a clean profile
DMD=1 mozrunner -b firefox/firefox
- Do whatever causes high heap-unclassified -- check in about:memory and note what the PID is
- From about:memory under Save DMD output click Save
- You should now have several
dmd-...-json.gz
files under/tmp
- Post-process the DMD file and attach the
dmd.txt
file here
# Run the dmd.py script from the firefox install, this will attempt to cleanup stacks so it might take a while
firefox/dmd.py -f24 -a -o dmd.txt /tmp/dmd-*-<PID>.json.gz
Comment 29•5 years ago
|
||
Thank you Eric, I will try to run this today and post the text file that is generated.
Comment 30•5 years ago
|
||
Here is the dmd.txt file from the session.
I have some more data which is more useful - when the Developer Tools were closed, the issue did not occur, and occasional spikes in memory were cleaned up in less than 15 seconds back to a typical baseline throughout my application.
However, when the Developer Tools were open, I saw the unclassified heap consistently grow and never release memory. This is the typical use case for my usage of the Developer Edition and vanilla Firefox, so it makes sense. I should note that since this was using a clean nightly build with a new profile, no developer extensions where enabled.
Comment 31•5 years ago
|
||
Thanks for the report. It looks like a lot of the unreported memory is allocated under WebGLShader::CompileShader(). Jeff, can you take a look please? Thanks.
Cameron, if you go to about:memory and click on Minimize Memory Usage, does that help? (It is possible that some garbage is hanging around that is keeping all of these WebGL data structures alive, because the GC isn't running because it isn't aware of the information being retained.)
Comment 32•5 years ago
|
||
This should probably get filed as a new bug. Piling in on an existing bug just makes it confusing for people to figure out what is going on.
Updated•5 years ago
|
Comment 33•5 years ago
|
||
Moving this discussion to the seemingly-related bug 1319426.
Description
•