native fetch with AbortController signal memory leak

[Robert-Schirmer]

Version

v18.16.0

Platform

Darwin robert.schirmer 21.6.0 Darwin Kernel Version 21.6.0: Thu Mar 9 20:12:21 PST 2023; root:xnu-8020.240.18.700.8~1/RELEASE_ARM64_T6000 arm64

Subsystem

undici

What steps will reproduce the bug?

Minimum reproducible repo here https://github.com/Robert-Schirmer/nodejs-mem-leak

Provide an AbortController signal to native Nodejs fetch

    const controller = new AbortController();

    await fetch("http://localhost:58080", {
      signal: controller.signal,
    });

Perform the fetch at least 1k times and memory will climb on v18.16.0

How often does it reproduce? Is there a required condition?

Using native fetch and providing an abort controller signal in the options of fetch has a slow memory leak every time using v18.16.0.

What is the expected behavior? Why is that the expected behavior?

No memory leak

What do you see instead?

Memory leak

Additional information

Memory leak does not exist in v18.15.0

The memory leak is fixed by nodejs/undici#2049 but v18.16.0 does not have those changes from the undici dependency.

[Mwni]

This leak exists in v18.9.1 as well though.

[GrantHynd]

I experienced the same issue you outlined using node 18.16.1, and can confirm that if you upgrade to 18.17.0 you won't experience the memory leak anymore. 18.17.0 contains the upgrade for undici that you mentioned and that resolves the issue.

[Uzlopak]

@mcollina

I guess if this is fixed in undici and thus in node 18.17.0 we can close this issue?!

[trivikr]

Looks like this issue can be closed, as the issue is not reproducible.

node v18.16.0

$ npm test
....
<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x1029b14fc node::Abort() [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
 2: 0x1029b16ec node::ModifyCodeGenerationFromStrings(v8::Local<v8::Context>, v8::Local<v8::Value>, bool) [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
 3: 0x102b070fc v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
 4: 0x102cb2088 v8::internal::EmbedderStackStateScope::EmbedderStackStateScope(v8::internal::Heap*, v8::internal::EmbedderStackStateScope::Origin, cppgc::EmbedderStackState) [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
 5: 0x102cb5c90 v8::internal::Heap::CollectSharedGarbage(v8::internal::GarbageCollectionReason) [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
 6: 0x102cb2c84 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*, v8::GCCallbackFlags) [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
 7: 0x102cb00dc v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
 8: 0x102cb9154 v8::internal::Heap::FinalizeIncrementalMarkingIfComplete(v8::internal::GarbageCollectionReason) [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
 9: 0x102cc6f98 v8::internal::IncrementalMarkingJob::Task::RunInternal() [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
10: 0x102a0f940 node::PerIsolatePlatformData::RunForegroundTask(std::__1::unique_ptr<v8::Task, std::__1::default_delete<v8::Task>>) [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
11: 0x102a0e5ac node::PerIsolatePlatformData::FlushForegroundTasksInternal() [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
12: 0x1032d0800 uv__async_io [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
13: 0x1032e2fa4 uv__io_poll [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
14: 0x1032d0cd0 uv_run [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
15: 0x1029016f4 node::SpinEventLoop(node::Environment*) [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
16: 0x1029ee8ec node::NodeMainInstance::Run() [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
17: 0x10297e028 node::LoadSnapshotDataAndRun(node::SnapshotData const**, node::InitializationResult const*) [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
18: 0x10297e2b4 node::Start(int, char**) [/Users/trivikram/Library/Application Support/fnm/node-versions/v18.16.0/installation/bin/node]
19: 0x18cfa1058 start [/usr/lib/dyld]
[1]    17921 abort      npm test

node v18.19.0

$ npm test
...
Iteration 9700
Iteration 9800
[18016:0x120008000]    49910 ms: Scavenge 23.7 (48.8) -> 19.1 (48.8) MB, 5.1 / 0.0 ms  (average mu = 0.998, current mu = 0.998) task; 
[18016:0x120008000]    49914 ms: Mark-sweep 19.1 (48.8) -> 7.7 (48.8) MB, 1.6 / 0.5 ms  (+ 1.1 ms in 17 steps since start of marking, biggest step 0.1 ms, walltime since start of marking 3 ms) (average mu = 0.998, current mu = 0.999) finalize incremental marking via task; GC in old space requested
Iteration 9900
Iteration 10000