Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leak with css animations #10872

Closed
cleoo opened this issue Nov 28, 2019 · 5 comments

Comments

@cleoo
Copy link

@cleoo cleoo commented Nov 28, 2019

Version

2.6.10

Reproduction link

https://codesandbox.io/s/vue-template-ygme1

Steps to reproduce

The given code adds a component containing a text (animated with css), removes it and starts again at infinity.
make different memory snapshots running the code and you'll see the number "detached html element" growing continuously.
if you remove the "resize" animation clause in the dummy component, no more "detached html element" appears in the snapshoots

Tested on Chromium 78.0.3904.108 *

What is expected?

Stable memory comsumption

What is actually happening?

Consumption of memory increases until the machine collapses

@posva posva added the need repro label Nov 28, 2019
@posva

This comment has been minimized.

Copy link
Member

@posva posva commented Nov 28, 2019

Could someone make sure the leak doesn't happen when using vanilla js? It doubt this comes from Vue if simply removing the CSS animation removes the leak.
@cleoo did you make sure you garbage collected before doing snapshots? Did you try on a regular html file? A codesandbox is far from ideal for a memory leak report

@cleoo

This comment has been minimized.

Copy link
Author

@cleoo cleoo commented Nov 30, 2019

I am aware the test is not really formal. We develop applications for interactive kiosks. On some very limited configurations (equivalent raspberry pi 3) the machine freezes completely in a few hours. By removing all the animations css the problem seems to disappear. I also agree that the problem is not necessarily related to Vuejs, we simply find that memory leaks are located in the browser.

I enclose some images, showing the evolution of the elements not released in time. I voluntarily did not trigger the garbage collector to simulate normal use

Capture d'écran Deepin_20191129002756
Capture d'écran Deepin_20191129002800
Capture d'écran Deepin_20191129002804
Capture d'écran Deepin_20191129002809

Quickly number of detached elements exceed 20000 without being deleted

@jeremy21212121

This comment has been minimized.

Copy link

@jeremy21212121 jeremy21212121 commented Dec 1, 2019

I tested using https://ygme1.csb.app/ to avoid the whole editor, using chromium on linux. I saw memory increase gradually from ~30mb until around 100-120mb when it dropped back down. None of my snapshots had a large number of detached HTML Div Elements.

I created a vanilla JS repro here. It exhibits similar memory usage, gradually increasing until eventually dropping suddenly.

I'd be curious to know how much of the system memory was in use when the device froze. Do you have a swap partition configured? The out-of-memory killer should kill the process if it exhausts system memory, unless you have a swap partition configured. If it starts swapping it would likely become unresponsive.

What linux distro are you running? Any useful info in the system logs (journalctl on systemd-based distros)?

@posva

This comment has been minimized.

Copy link
Member

@posva posva commented Dec 1, 2019

Thanks @jeremy21212121

I also agree that the problem is not necessarily related to Vuejs, we simply find that memory leaks are located in the browser.

@cleoo that's important as we can only fix the leak if the problem comes from Vue, not from the browser, which can also create leaks. In that case, the problem should be reported in chromium bug tracker using a vanilla repro like the above.
By garbage collection I mean clicking the garbage icon right under the Elements panel. When doing that, you will see the heap snapshots do not increase in size

@posva posva closed this Dec 1, 2019
@posva posva removed the need repro label Dec 1, 2019
@cleoo

This comment has been minimized.

Copy link
Author

@cleoo cleoo commented Dec 1, 2019

I'd be curious to know how much of the system memory was in use when the device froze. Do you have a swap partition configured? The out-of-memory killer should kill the process if it exhausts system memory, unless you have a swap partition configured. If it starts swapping it would likely become unresponsive.

What linux distro are you running? Any useful info in the system logs (journalctl on systemd-based distros)?

Thank you for the time devoted to our concern. The system (archlinux) freezes even with swap. I have been monitoring the behavior of a modified installation for two days and confirms that removing the animations only corrects the problem (the memory usage remains stable). The visual damage is not very important, only pictograms (font-awesome) were animated.

I saw memory increase gradually from ~30mb until around 100-120mb when it dropped back down

I have the same behavior on my development machine, under rpi / arm the release seems not to be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.