-
Notifications
You must be signed in to change notification settings - Fork 46.7k
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 on React > 16.2.5 #14732
Comments
We've encountered similiar issue on 16.6.3. May be it was already fixed by this? |
Sadly no, that had been our hope but leak persists. |
We had similar problem but we fixed that by upgrading react-dom and react lib to 16.7 |
The only relevant fix I'm aware of is #14276 which got into 16.7.0. We'd need a reproducing case to help more. Remember to test production version, and also that we retain a reference to deleted children for one more update (#12420 (comment)). |
Updating from React 16.6 to 16.8 drastically improved our memory usage, but it's still there, slow and inexorable. Currently I have installed react and react-dom 16.8.6. More info: I'm using Electron, BlueprintJS and Redux, I have a polling component that updates itself making some http requests and dispatching a Redux action. From devtools I can see a lot of FiberNode and they are never deleted, they just keep growing. My naive implementation of the component it's something like this: class MyComponent extends Component {
componentDidMount = () => {
this.interval = setInterval(this.tick, 1000);
};
componentWillUnmount = () => {
clearInterval(this.interval);
};
tick = async () => {
if (this.updating) {
return;
}
this.updating = true;
try {
// dispatch async (thunk middleware) redux action,
// this will trigger an API and maybe a re-render this component
await this.props.doUpdate();
} catch (e) {
/* handle error */
}
this.updating = false;
};
render() {
<span>{this.props.myState}</span>
}
} if I can help providing any information, just let me know. Thanks! |
I have very similar memory leak with video and audio elements, perhaps related in some way? Do you find a lot of detached nodes if you create a heap snapshot under memory and search for detached in the class filter? You can check out my issue here, which is very easy to reproduce with a simple demo: #15583 |
We have a somewhat similar memory leak (although we're experiencing it on all React 16.x versions) where there are a lot of detached nodes that never get garbage collected. The issue goes away if we downgrade to React 15.x. You can see the documentation in this issue (along with a reproducible example): #15637 |
I've got the same problem. Any one solved this problem except demotion? |
There is an open PR #15157. |
This case maybe helpful. |
Here is a repro: https://codesandbox.io/s/compassionate-fermat-3cq5b Simply uncomment line 7 and the page will continue to grow in heap until it OOMs. |
Not sure if related somehow, but I've been seeing this message a lot and the app takes a long time to hot reload during local development:
Navigating to certain pages just hangs the browser and I have to kill the task. This seems to have started recently when we updated some packages. |
Any update on this ? |
#16115 was recently merged and will be out in 16.9.0. It might improve things. |
Upgrading to |
Oddly, upgrading to |
What minifier are you using? We’ve seen perf issues caused by a buggy minifier version. |
Very interesting, @gaearon, thanks for the tip. I'm using EDIT: I was able to resolve a couple memory leaks in my own application. Unfortunately this didn't move the needle. However, applying #15157 cut the leak from 5MB to <1MB. Hopefully that MR will go in soon :) EDIT: Issue is ongoing. Here are a collection of heap snapshots with 10 tree remounts in between each snapshot. This is without #15157 applied. It appears that react is the culprit, but perhaps devtools is misleading here, and user-land memory leaks will appear to originate in react? Any advice greatly appreciated! :) |
@gaearon and all, if I use both drag and drop, will raise memory leak
` |
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment! |
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you! |
Do you want to request a feature or report a bug?
Possible bug, or unexpected change in internal behavior
What is the current behavior?
We are seeing a substantial memory leak in our codebase in versions of React > 16.5.2. Bisecting the issue, it seemed to appear at commit 7bee9fb.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:
Our apologies, we are unable to fully isolate the issue to a minimal demo, and suspect it is not a bug but a behavior change which our code relied on. The leak seems to be in the messages area, where many components are created and released quickly.
What is the expected behavior?
Old fibers should be garbage collected, but cannot be. Components are retained in memory.
We have run the affected code area in StrictMode, which allowed us to identify some event leakage but even when this was addressed (by moving listeners to componentDidMount from the constructor) the memory leak continues. There are some findDomNode usages remaining, but even if we move those it does not fill the leak.
Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
16.5.3+
We are seeking suggestions on what internal could be causing retention of components and nodes by our code, and better ways to isolate the issue.
Thank you!
-Mike
The text was updated successfully, but these errors were encountered: