-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
native fetch with AbortController signal memory leak #48478
Comments
This leak exists in v18.9.1 as well though. |
node's native fetch has a memory leak: nodejs/node#48478
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. |
I guess if this is fixed in undici and thus in node 18.17.0 we can close this issue?! |
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 |
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
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.
The text was updated successfully, but these errors were encountered: