8000 `pnpm audit` crashes with out-of-memory error · Issue #9280 · pnpm/pnpm · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

pnpm audit crashes with out-of-memory error #9280

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

Closed
2 of 4 tasks
NullVoxPopuli opened this issue Mar 13, 2025 · 3 comments · Fixed by #9290
Closed
2 of 4 tasks

pnpm audit crashes with out-of-memory error #9280

NullVoxPopuli opened this issue Mar 13, 2025 · 3 comments · Fixed by #9290

Comments

@NullVoxPopuli
Copy link
Contributor

Verify latest release

  • I verified that the issue exists in the latest pnpm release

pnpm version

10.6.3, 10.5.2

Which area(s) of pnpm are affected? (leave empty if unsure)

CLI

Link to the code that reproduces this issue or a replay of the bug

No response

Reproduction steps

pnpm audit

Describe the Bug

❯ pnpm audit

<--- Last few GCs --->

[49077:0x150008000]   169350 ms: Mark-Compact 8077.0 (8238.9) -> 8074.1 (8238.9) MB, pooled: 0 MB, 3737.79 / 0.00 ms  (average mu = 0.170, current mu = 0.034) allocation failure; scavenge might not succeed
[49077:0x150008000]   174575 ms: Mark-Compact 8259.9 (8408.9) -> 8143.9 (8322.3) MB, pooled: 0 MB, 5188.83 / 0.00 ms  (average mu = 0.082, current mu = 0.007) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x1028cb1e4 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [🏠/.proto/tools/node/22.14.0/bin/node]
 2: 0x102acafd8 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [🏠/.proto/tools/node/22.14.0/bin/node]
 3: 0x102cd8f30 v8::internal::Heap::stack() [🏠/.proto/tools/node/22.14.0/bin/node]
 4: 0x102cd72d0 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [🏠/.proto/tools/node/22.14.0/bin/node]
 5: 0x102ccb8b8 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [🏠/.proto/tools/node/22.14.0/bin/node]
 6: 0x102ccc0f0 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [🏠/.proto/tools/node/22.14.0/bin/node]
 7: 0x102caf410 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [🏠/.proto/tools/node/22.14.0/bin/node]
 8: 0x1030caae4 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [🏠/.proto/tools/node/22.14.0/bin/node]
 9: 0x10358de9c Builtins_WasmCEntry [🏠/.proto/tools/node/22.14.0/bin/node]
10: 0x10358e2e4 Builtins_StringAdd_CheckNone [🏠/.proto/tools/node/22.14.0/bin/node]
11: 0x109362dc8
12: 0x109362f58
13: 0x109362f58
14: 0x109362f58
15: 0x109362f58
16: 0x109362f58
17: 0x109362f58
18: 0x109362f58
19: 0x109362f58
20: 0x109362f58
21: 0x109360874
22: 0x109360f3c
23: 0x103535290 Builtins_AsyncFunctionAwaitResolveClosure [🏠/.proto/tools/node/22.14.0/bin/node]
24: 0x1036004d8 Builtins_PromiseFulfillReactionJob [🏠/.proto/tools/node/22.14.0/bin/node]
25: 0x103525594 Builtins_RunMicrotasks [🏠/.proto/tools/node/22.14.0/bin/node]
26: 0x1034f6af4 Builtins_JSRunMicrotasksEntry [🏠/.proto/tools/node/22.14.0/bin/node]
27: 0x102c30e6c v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [🏠/.proto/tools/node/22.14.0/bin/node]
28: 0x102c31714 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [🏠/.proto/tools/node/22.14.0/bin/node]
29: 0x102c3184c v8::internal::Execution::TryRunMicrotasks(v8::internal::Isolate*, v8::internal::MicrotaskQueue*) [🏠/.proto/tools/node/22.14.0/bin/node]
30: 0x102c5eac8 v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) [🏠/.proto/tools/node/22.14.0/bin/node]
31: 0x102c5f24c v8::internal::MicrotaskQueue::PerformCheckpoint(v8::Isolate*) [🏠/.proto/tools/node/22.14.0/bin/node]
32: 0x1027d59a8 node::InternalCallbackScope::Close() [🏠/.proto/tools/node/22.14.0/bin/node]
33: 0x1027d5cc4 node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context, v8::Local<v8::Value>) [🏠/.proto/tools/node/22.14.0/bin/node]
34: 0x1027eafd4 node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [🏠/.proto/tools/node/22.14.0/bin/node]
35: 0x1028d0dbc node::fs::FSReqCallback::Resolve(v8::Local<v8::Value>) [🏠/.proto/tools/node/22.14.0/bin/node]
36: 0x1028d14b0 node::fs::AfterNoArgs(uv_fs_s*) [🏠/.proto/tools/node/22.14.0/bin/node]
37: 0x1028c3b3c node::MakeLibuvRequestCallback<uv_fs_s, void (*)(uv_fs_s*)>::Wrapper(uv_fs_s*) [🏠/.proto/tools/node/22.14.0/bin/node]
38: 0x1034d065c uv__work_done [🏠/.proto/tools/node/22.14.0/bin/node]
39: 0x1034d410c uv__async_io [🏠/.proto/tools/node/22.14.0/bin/node]
40: 0x1034e7920 uv__io_poll [🏠/.proto/tools/node/22.14.0/bin/node]
41: 0x1034d4674 uv_run [🏠/.proto/tools/node/22.14.0/bin/node]
42: 0x1027d6508 node::SpinEventLoopInternal(node::Environment*) [🏠/.proto/tools/node/22.14.0/bin/node]
43: 0x102914154 node::NodeMainInstance::Run() [🏠/.proto/tools/node/22.14.0/bin/node]
44: 0x10288a364 node::Start(int, char**) [🏠/.proto/tools/node/22.14.0/bin/node]
45: 0x197fc8274 start [/usr/lib/dyld]
Abort trap: 6

Expected Behavior

prints the audit output, no error

Which Node.js version are you using?

22.14.0

Which operating systems have you used?

  • macOS
  • Windows
  • Linux

If your OS is a Linux based, which one it is? (Include the version if relevant)

No response

@NullVoxPopuli
Copy link
Contributor Author

I just whipped up a tool to prove that traversing unique deps is possible to do quickly:
https://github.com/NullVoxPopuli/how-many-deps

scans a whole 3 million line -sized monorepo in 3-9s on macOS.

So, I suspect pnpm audit is potentially OOM-ing because its trying to provide every path in the dep graph to a particular vulnerable dependency.

Would it be reasonable to skip that step? Its helpful information, but not particularly needed in my use cases.

@NullVoxPopuli
Copy link
Contributor Author

I confirm that it's the paths code in extendWithDependencyPaths.

I patch'd that code out, and not only does audit not OOM, it finishes in ~ 5s

@zkochan
Copy link
Member
zkochan commented Mar 14, 2025

Yes, I am good with removing paths.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
0