fix(jest-leak-detector): gc() even harder #10994
Conversation
FauxFaux
force-pushed
the
feat/gc-harder
branch
from
1a5e32f to
f821ce3
Compare
|
This PR is stale because it has been open 1 year with no activity. Remove stale label or comment or this will be closed in 30 days. |
jest-leak-detector declares a leak in some of our large projects, a leak which does not exist. I have bisected it down to there being too deep require() trees, and/or too many files loaded. It is definitely not a timing issue; replacing the extra gc() with a multi-second sleep does not fix it. Calling gc() from the app code surprisingly does fix it, at least, for us. My working theory is that the app's gc() takes out some of the actual garbage, leaving leak-detector's gc() time to actually collect all of the code, resulting, eventually, in no leak. I realise this is hot garbage. I'm absolutely not going to try and write a test for this, and I understand if you close the PR with nelson.gif, and I will continue running with hacks, or try and raise a PR which allows the leak-detector implementation to be configurable.
FauxFaux
force-pushed
the
feat/gc-harder
branch
from
f821ce3 to
47c3b88
Compare
|
I suspect this is still useful, given other people have raised it. I haven't tested it against the new leak detector code, with FinalisationRegistry, though. |
|
If a test can be added that shows that it works properly with more |
|
This PR is stale because it has been open 1 year with no activity. Remove stale label or comment or this will be closed in 30 days. |
|
This PR was closed because it has been stalled for 30 days with no activity. Please open a new PR if the issue is still relevant, linking to this one. |
|
FWIW, GC run was made more aggressive in #14526 |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
jest-leak-detector declares a leak in some of our large projects,
a leak which does not exist. I have bisected it down to there
being too deep require() trees, and/or too many files loaded.
It is definitely not a timing issue; replacing the extra gc() with
a multi-second sleep does not fix it. Calling gc() from the app code
surprisingly does fix it, at least, for us. My working theory is that
the app's gc() takes out some of the actual garbage, leaving
leak-detector's gc() time to actually collect all of the code,
resulting, eventually, in no leak.
I realise this is hot garbage. I'm absolutely not going to try and
write a test for this, and I understand if you close the PR with
nelson.gif, and I will continue running with hacks, or try and
raise a PR which allows the leak-detector implementation to be
configurable.
Tested on node 12 and 14, same behaviour.
Test plan
I really advise that you don't.
There are tests which cover the leak detector's behaviour, and they are not broken.