Skip to content
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

SIGSEGV on v8.getHeapSnapshot() #38961

Closed
avivbarel opened this issue Jun 7, 2021 · 3 comments
Closed

SIGSEGV on v8.getHeapSnapshot() #38961

avivbarel opened this issue Jun 7, 2021 · 3 comments
Labels
v8 module Issues and PRs related to the "v8" subsystem.

Comments

@avivbarel
Copy link

  • Version: v14.17.0
  • Platform: Darwin -myhostname- 20.5.0 Darwin Kernel Version 20.5.0: Sat May 8 05:10:31 PDT 2021; root:xnu-7195.121.3~9/RELEASE_ARM64_T8101 arm64
  • Subsystem: v8 module

What steps will reproduce the bug?

Not sure about exact steps, but I think running puppeteer (running here 5 browser instances) and while it is running, invoke v8.getHeapSnapshot() by signal - doesn't matter which one, as long as you ignore it's side effect or that it does not change stuff. In my scenario the tested signals were SIGUSR1, SIGCONT, SIGWINCH.

So a pseudocode would look like this:

// ... run puppeteer code in background
const v8 = require('v8');
process.on('SIGUSR1', () => {
    const snapshotStream =  v8.getHeapSnaphshot();
    // ... should crash right about here ...
})

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

Once signal is sent to the process, I guess any other trigger will cause the same effect.

What is the expected behavior?

A successfully generated heap snapshot stream which can later be written to some I/O.

What do you see instead?

zsh: segmentation fault

But in order to get more details I used the segfault-handler package (https://www.npmjs.com/package/segfault-handler):

PID 80740 received SIGSEGV for address: 0x200000018
0   segfault-handler.node               0x0000000104a61344 _ZL16segfault_handleriP9__siginfoPv + 292
1   libsystem_platform.dylib            0x000000018a4e6c44 _sigtramp + 56
2   node                                0x0000000100b9beac _ZN2v88internal14V8HeapExplorer24ExtractContextReferencesEPNS0_9HeapEntryENS0_7ContextE + 344
3   node                                0x0000000100b9dbc0 _ZN2v88internal14V8HeapExplorer27IterateAndExtractReferencesEPNS0_21HeapSnapshotGeneratorE + 796
4   node                                0x0000000100b9fc94 _ZN2v88internal21HeapSnapshotGenerator16GenerateSnapshotEv + 184
5   node                                0x0000000100b9561c _ZN2v88internal12HeapProfiler12TakeSnapshotEPNS_15ActivityControlEPNS_12HeapProfiler18ObjectNameResolverEb + 112
6   node                                0x0000000100630a64 _ZN4node4heap24CreateHeapSnapshotStreamERKN2v820FunctionCallbackInfoINS1_5ValueEEE + 124
7   node                                0x00000001007f050c _ZN2v88internal25FunctionCallbackArguments4CallENS0_15CallHandlerInfoE + 540
8   node                                0x00000001007efb18 _ZN2v88internal12_GLOBAL__N_119HandleApiCallHelperILb0EEENS0_11MaybeHandleINS0_6ObjectEEEPNS0_7IsolateENS0_6HandleINS0_10HeapObjectEEESA_NS8_INS0_20FunctionTemplateInfoEEENS8_IS4_EENS0_16BuiltinArgumentsE + 444
9   node                                0x00000001007ef3b0 _ZN2v88internalL26Builtin_Impl_HandleApiCallENS0_16BuiltinArgumentsEPNS0_7IsolateE + 224
10  node                                0x0000000100f0a40c Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit + 108
11  node                                0x0000000100ea3054 Builtins_InterpreterEntryTrampoline + 244
12  node                                0x0000000100ea3054 Builtins_InterpreterEntryTrampoline + 244
13  node                                0x0000000100e9be24 Builtins_ArgumentsAdaptorTrampoline + 228
14  node                                0x0000000100ea3054 Builtins_InterpreterEntryTrampoline + 244
15  node                                0x0000000100e9be24 Builtins_ArgumentsAdaptorTrampoline + 228
16  node                                0x0000000100ea3054 Builtins_InterpreterEntryTrampoline + 244
17  node                                0x0000000100e9be24 Builtins_ArgumentsAdaptorTrampoline + 228
18  node                                0x0000000100ea0904 Builtins_JSEntryTrampoline + 164
19  node                                0x0000000100ea05a8 Builtins_JSEntry + 168
20  ???                                 0x0000000140008000 0x0 + 5368741888

Additional information

My theory is that because there are chrome instances running in the background, whether in child processes or wherever, the function v8.getHeapSnapshot() thinks node has more memory space than it actually has.

@Ayase-252 Ayase-252 added the v8 module Issues and PRs related to the "v8" subsystem. label Jun 8, 2021
@gengjiawen
Copy link
Member

cc @joyeecheung

@joyeecheung
Copy link
Member

Have you tried running this on a newer release of Node.js? What kind of puppeteer code do you run?

It is difficult to tell from the stack trace what operation triggers the SIGSEGV, it may be more informative if you can configure your system to generate a coredump when it crashes so that it's possible to see exactly where it crashed.

@legendecas
Copy link
Member

Tracking in #42558.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v8 module Issues and PRs related to the "v8" subsystem.
Projects
None yet
Development

No branches or pull requests

5 participants