Uh oh!
There was an error while loading. Please reload this page.
lib: fix timer leak - #53337
Conversation
e25d0ab to
4eda87fComparemitsuhiko
commented
Jun 4, 2024
Thank you for fixing this! Small nit I noticed: |
nodejs-github-bot
commented
Jun 5, 2024
nodejs-github-bot
commented
Jun 5, 2024
nodejs-github-bot
commented
Jun 5, 2024
nodejs-github-bot
commented
Jun 7, 2024
Landed in 2740cd4 |
PR-URL: nodejs#53337Fixes: nodejs#53335 Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Feng Yu <F3n67u@outlook.com> Reviewed-By: Yagiz Nizipli <yagiz.nizipli@sentry.io>
will this be downported to node v18? I see that PR is included in |
atlowChemi
commented
Jun 26, 2024
@soccermax |
soccermax
commented
Jun 26, 2024
@atlowChemi, thanks for the reply. That makes sense. This issue might cause a significant memory leak. I believe it would be beneficial to backport the fix to Node versions which are still in maintenance. The explanation is that the closure of setTimeout might hold references to memory-intensive objects like database connections, response objects, or similar. Due to this issue, the entire closure of setTimeout, if the return object of setTimeout is used, will be indefinitely retained in memory. In our project, this leaks memory of around 300MB per day. The problem is that the troubling setTimeout is called in a submodule. Of course, we can patch the library, but in general, it would make sense to get it fixed directly in Node. Given that the fix is quite small, it would be highly appreciated if it could be backported. Could you please check on this? Thanks. |
richardlau
commented
Sep 19, 2024
Unfortunately this doesn't cherry-pick cleanly to v18.x-staging. Since Node.js 18 is in maintenance it's unlikely this will be accepted, but if someone wants to try (on the understanding the PR might be turned down) they can open a backport PR against v18.x-staging. |
Fixes: #53335
make -j4 test(UNIX), orvcbuild test(Windows) passes