Skip to content
This repository has been archived by the owner on Mar 23, 2023. It is now read-only.

memory leak with MenuTab component #1496

Closed
alessiodf opened this issue Oct 2, 2019 · 8 comments
Closed

memory leak with MenuTab component #1496

alessiodf opened this issue Oct 2, 2019 · 8 comments
Labels
Type: Bug The issue relates to broken or incorrect behaviour.

Comments

@alessiodf
Copy link
Contributor

Components inside a MenuTabItem can cause a memory leak if any of the props of the component change often. This is problematic for plugins that make use of the MenuTab.

Whatever value is set as a prop is stored in memory. Even when the value of the prop changes, the old value is retained in memory too. So if the prop value changes constantly, all the previous values are still stored in memory too. This will cause the memory usage to rise and rise and rise until it runs out of memory and aborts or crashes.

When the component is not inside a MenuTabItem the old prop values are not stored in memory, thus there is no leak. That means the problem lies within the MenuTab and MenuTabItem components.

Expected Behavior

There should not be a memory leak.

Current Behavior

There is a memory leak.

Steps to Reproduce (for bugs)

I'm not able to provide a live demo or code at present but please reach out to me if necessary. In the meantime, steps to reproduce are as follows:

  1. Create a new component with a prop. It's easier to replicate if your prop is an array with many values, but it works with strings too.
  2. Include that new component as a MenuTabItem within a MenuTab.
  3. Set up a method/loop/timer to change the value of the prop.
  4. Check your memory usage in the dev tools, it will rise until it eventually crashes with an OOM error.
  5. Place the component outside of the MenuTab hierarchy and repeat the test.
  6. The memory usage will remain constant, or may rise slightly but will go back down when the GC runs.

Context

It is inhibiting my work creating plugins as I have to try to make a clone of the MenuTab component sans memory leak. If my component inside the MenuTab remains open for long enough, it'll crash with an OOM error because the prop value continually changes. If I isolate it outside of a MenuTab the memory usage remains low and static.

Your Environment

  • Version used: develop and 2.6.2
  • Operating System and version: macOS 10.14.6
@ghost
Copy link

ghost commented Oct 2, 2019

Thanks for opening this issue! A maintainer will review this in the next few days and explicitly select labels so you know what's going on.

If no reviewer appears after a week, a reminder will be sent out.

@alessiodf
Copy link
Contributor Author

alessiodf commented Oct 4, 2019

vuejs/vue#9842 looks very similar but it is not the same. The open (and seemingly stale) PRs to resolve it don't fix this issue (e.g. vuejs/vue#9875) as I just tested them.

@alexbarnsley alexbarnsley added the Type: Bug The issue relates to broken or incorrect behaviour. label Oct 23, 2019
@dav1app
Copy link
Contributor

dav1app commented Jan 20, 2020

Is this related to #1498?

I'm creating the code to reproduce this issue.

@dav1app
Copy link
Contributor

dav1app commented Jan 20, 2020

I've created the following environment for the test. Everything is created using clean vue create. Everything else is untouched on purpose.

components
├── HelloWorld.vue
├── MenuTab 
│   ├── Index.js
│   ├── MenuTabItem.vue
├── utils
│   ├── VNodes.js
<template>
  <div>
    <MenuTab>
      <MenuTabItem label="nothing" :badguy="badguy" />
    </MenuTab>
  </div>
</template>

And using setInterval to trigger the changes. Memory seams to stay ok.

Could you please provide more details on how to reproduce this issue? If you send me your repo I could take a look into it.

@alessiodf
Copy link
Contributor Author

I have been able to reproduce this on the current develop branch and will be in touch soon once I've discussed the next steps with @alexbarnsley 👍🏻

@alessiodf
Copy link
Contributor Author

Okay, code sent to Alex. Hopefully you guys will be able to take it from there!

@faustbrian
Copy link
Contributor

Closing, no longer relevant for 3.0

@ghost
Copy link

ghost commented Jun 18, 2020

This issue has been closed. If you wish to re-open it please provide additional information.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Type: Bug The issue relates to broken or incorrect behaviour.
Projects
None yet
Development

No branches or pull requests

4 participants