Repository navigation
Flaky GC-related tests with V8 12.2 #52273
Description
Activity
- added 2 commits that reference this issue
on Mar 30, 2024 Not sure if it's exactly related to
test-net-write-fully-async-hex-string, but just something I notice: I discovered in my Oilpan migration prototypes that we may be under reporting externally-managed memory (#40786 (comment)), leading to poor GC performance.@legendecas an FYI as I think you were working on shadow realm related stuff?
- added a commit that references this issue
on May 8, 2024 - added a commit that references this issue
on May 11, 2024 - added a commit that references this issue
on Jun 20, 2024 @targos @joyeecheung ... can either of you update here on what is needed to address the flaky tests? For test-net-write-fully-async-hex-string, it's not clear from the discussion here what the issue might be or how the test might need to change and I've been unable to reproduce any failure locally.
FWIW I found that when I increased the
--max-old-space-sizeflag intest-shadow-realm-gc.jsfrom20to25, it greatly reduced the failures (but not entirely removed them).
I also couldn't reproduce the
test-net-write-fully-async-hex-stringandtest-shadow-realm-gc-modulefailures.- added a commit that references this issue
on May 8, 2025 I tried to enable the tests in #58232
Failure: https://github.com/nodejs/node/actions/runs/14905536948/job/41866906957?pr=58232
=== release test-shadow-realm-gc === Path: parallel/test-shadow-realm-gc Error: --- stderr --- node:events:485 throw er; // Unhandled 'error' event ^ Error [ERR_WORKER_OUT_OF_MEMORY]: Worker terminated due to reaching memory limit: JS heap out of memory at [kOnExit] (node:internal/worker:314:26) at Worker.<computed>.onexit (node:internal/worker:230:20) Emitted 'error' event on Worker instance at: at [kOnExit] (node:internal/worker:314:12) at Worker.<computed>.onexit (node:internal/worker:230:20) { code: 'ERR_WORKER_OUT_OF_MEMORY' } Node.js v25.0.0-pre Command: out/Release/node --experimental-shadow-realm --max-old-space-size=20 --test-reporter=./test/common/test-error-reporter.js --test-reporter-destination=stdout /Users/runner/work/node/node/node/test/parallel/test-shadow-realm-gc.js === === 1 tests failed === Failed tests: out/Release/node --experimental-shadow-realm --max-old-space-size=20 --test-reporter=./test/common/test-error-reporter.js --test-reporter-destination=stdout /Users/runner/work/node/node/node/test/parallel/test-shadow-realm-gc.jsI think the worker thread changes (or any changes in that direction) could make the tests more flaky, not less, because it would be less likely for any unblocking GC from any thread to block the main thread - performance wise that's a good thing, however, the tests generally count on GC to kick in and finish fast enough that the heap growth would not reach limit of the heap, they assume when the memory pressure is critical enough the whole world will stop and wait for GC before moving forward (they tried queuing foreground tasks in the event loop, which I don't think would do the trick now) which may not necessarily be a safe assumption especially for a very small heap limit value so that V8 doesn't have a lot of wiggle room to work with.
I think to make them more reliable it's between to just rewrite with something like checkIfCollectableByCounting and don't count on heap limits.
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
re.
test-shadow-realm-gc-moduleandtest-shadow-realm-gc, I think we should just skip them. Possible solution can be, use the more reliablecheckIfCollectableByCounting()to check if the ShadowRealm instance in the main context can be collected, but I feel that would make the test invalid too (e.g. the native side can still be leaking even though the JS instances are collectable), so we might as well just skip and figure out a better way to test it later.re.
test-net-write-fully-async-hex-string, looks like it's related to--expose-gcagain. I'd suggest that we just open an issue to track this and the shadow realm tests, and skip them for now. They are likely flaking due to incorrect assumptions in the tests broken by V8's new GC strategy, not real bugs.Originally posted by @joyeecheung in #51362 (comment)