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

2.0.x: Segmentation fault when starting with NODE_OPTIONS=--max-old-space-size=4096 #12695

Closed
bpasero opened this Issue Apr 24, 2018 · 10 comments

Comments

Projects
None yet
9 participants
@bpasero
Contributor

bpasero commented Apr 24, 2018

  • Electron version: 2.0-beta.7
  • Operating system: macOS 10.13.4
  • Last known working Electron version: 1.7.9

Expected behavior

It should not crash.

Actual behavior

It crashes.

How to reproduce

  • open a terminal
  • export NODE_OPTIONS=--max-old-space-size=4096
  • ./Electron

Output:
Segmentation fault: 11

Process:               Electron [36848]
Path:                  /Users/USER/Desktop/*/Electron.app/Contents/MacOS/Electron
Identifier:            Electron
Version:               2.0.0 (2.0.0)
Code Type:             X86-64 (Native)
Parent Process:        bash [33208]
Responsible:           Electron [36848]
User ID:               501

Date/Time:             2018-04-24 11:16:03.250 +0200
OS Version:            Mac OS X 10.13.4 (17E199)
Report Version:        12
Anonymous UUID:        E22FC843-9C95-2329-B911-4033726E6AFD

Sleep/Wake UUID:       8E3050B7-C177-4084-A5E0-7C8406AEB847

Time Awake Since Boot: 24000 seconds
Time Since Wake:       740 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

VM Regions Near 0:
--> 
    __TEXT                 000000010d9f6000-000000010d9f7000 [    4K] r-x/rwx SM=COW  /Users/USER/Desktop/*/Electron.app/Contents/MacOS/Electron

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libnode.dylib                 	0x000000010dc1bf7b node::Init(int*, char const**, int*, char const***) + 747 (node.cc:4641)
1   com.github.electron.framework 	0x000000010f2fc879 atom::NodeBindings::Initialize() + 41 (node_bindings.cc:180)
2   com.github.electron.framework 	0x000000010f2681f0 atom::AtomBrowserMainParts::PostEarlyInitialization() + 192 (atom_browser_main_parts.cc:135)
3   com.github.electron.framework 	0x000000010f6ce679 content::BrowserMainLoop::EarlyInitialization() + 233 (browser_main_loop.cc:613)
4   com.github.electron.framework 	0x000000010f6d42a2 content::BrowserMainRunnerImpl::Initialize(content::MainFunctionParams const&) + 610 (browser_main_runner.cc:111)
5   com.github.electron.framework 	0x000000010f6cde44 content::BrowserMain(content::MainFunctionParams const&) + 100 (browser_main.cc:42)
6   com.github.electron.framework 	0x000000010f617030 content::ContentMainRunnerImpl::Run() + 368 (content_main_runner.cc:686)
7   com.github.electron.framework 	0x000000011120c494 service_manager::Main(service_manager::MainParams const&) + 2772 (main.cc:469)
8   com.github.electron.framework 	0x000000010f615e44 content::ContentMain(content::ContentMainParams const&) + 68 (content_main.cc:19)
9   com.github.electron.framework 	0x000000010f1c3cc4 AtomMain + 68 (atom_library_main.mm:24)
10  com.github.electron           	0x000000010d9f6f26 main + 38 (atom_main.cc:185)
11  libdyld.dylib                 	0x00007fff5b3d3015 start + 1
@sla89

This comment has been minimized.

Show comment
Hide comment
@sla89

sla89 Apr 24, 2018

Same on

Electron version: 1.8.3
Operating system: Ubuntu 16.04

when setting NODE_OPTIONS=--use-openssl-ca.

sla89 commented Apr 24, 2018

Same on

Electron version: 1.8.3
Operating system: Ubuntu 16.04

when setting NODE_OPTIONS=--use-openssl-ca.

@codebytere codebytere self-assigned this Apr 24, 2018

@codebytere

This comment has been minimized.

Show comment
Hide comment
@codebytere

codebytere Apr 24, 2018

Member

Looks like a startup crash in node.cc:

   4492     const char** argv_from_env = new const char*[max_len];
   4493     int argc_from_env = 0;
   4494     // [0] is expected to be the program name, fill it in from the realargv.
-> 4495     argv_from_env[argc_from_env++] = argv[0];
   4496
   4497     char* cstr = strdup(node_options.c_str());
   4498     char* initptr = cstr;

will continue to investigate

Member

codebytere commented Apr 24, 2018

Looks like a startup crash in node.cc:

   4492     const char** argv_from_env = new const char*[max_len];
   4493     int argc_from_env = 0;
   4494     // [0] is expected to be the program name, fill it in from the realargv.
-> 4495     argv_from_env[argc_from_env++] = argv[0];
   4496
   4497     char* cstr = strdup(node_options.c_str());
   4498     char* initptr = cstr;

will continue to investigate

@codebytere

This comment has been minimized.

Show comment
Hide comment
@codebytere

codebytere May 2, 2018

Member

It looks like when NODE_OPTIONS are set that argv[0] is never getting populated as it should

Member

codebytere commented May 2, 2018

It looks like when NODE_OPTIONS are set that argv[0] is never getting populated as it should

@bpasero

This comment has been minimized.

Show comment
Hide comment
@bpasero

bpasero Jun 9, 2018

Contributor

Can we prioritise this into a possible 2.0.3 release? There also seems to be quite a bit of related issues linked to this one by now.

Contributor

bpasero commented Jun 9, 2018

Can we prioritise this into a possible 2.0.3 release? There also seems to be quite a bit of related issues linked to this one by now.

@codebytere

This comment has been minimized.

Show comment
Hide comment
@codebytere

codebytere Jun 9, 2018

Member

@bpasero I'll devote some solid time to this on Monday!

Member

codebytere commented Jun 9, 2018

@bpasero I'll devote some solid time to this on Monday!

@bpasero

This comment has been minimized.

Show comment
Hide comment
@bpasero

bpasero Jun 10, 2018

Contributor

@codebytere thanks 👍

Contributor

bpasero commented Jun 10, 2018

@codebytere thanks 👍

@SamCosby

This comment has been minimized.

Show comment
Hide comment
@SamCosby

SamCosby Jun 12, 2018

This looks to affect MS Teams as well, since it's also built on top of Electron.

SamCosby commented Jun 12, 2018

This looks to affect MS Teams as well, since it's also built on top of Electron.

@sethlu

This comment has been minimized.

Show comment
Hide comment
@sethlu

sethlu Jun 15, 2018

Member

@bpasero It turns out that NODE_OPTIONS would always crash Electron. A short term fix would be to make this env variable do nothing so this wouldn't be a breaking change in Electron since it's not really documented in Electron. Then we can move on to working on a fix to support NODE_OPTIONS.

cc: @codebytere @nitsakh @gnahzak

Member

sethlu commented Jun 15, 2018

@bpasero It turns out that NODE_OPTIONS would always crash Electron. A short term fix would be to make this env variable do nothing so this wouldn't be a breaking change in Electron since it's not really documented in Electron. Then we can move on to working on a fix to support NODE_OPTIONS.

cc: @codebytere @nitsakh @gnahzak

@gnahzak

This comment has been minimized.

Show comment
Hide comment
@gnahzak

gnahzak Jun 19, 2018

Contributor

Since the last comment, we've tried the following to diagnose the issue:

  • The exception happens in node.cc due to the assumption that dereferencing argv[0] is always valid
  • The issue is directly caused by calling node::Init() with a null pointer for argv
  • The block is guarded by NODE_WITHOUT_NODE_OPTIONS
  • We want to define NODE_WITHOUT_NODE_OPTIONS so the code containing this call is skipped over, but doing so in electron.gyp was unsuccessful

The temporary solution is to add NODE_WITHOUT_NODE_OPTIONS in node.gyp, but we still need to investigate why the .gyp config file definitions don't propagate.

@sethlu @codebytere @nitsakh

Contributor

gnahzak commented Jun 19, 2018

Since the last comment, we've tried the following to diagnose the issue:

  • The exception happens in node.cc due to the assumption that dereferencing argv[0] is always valid
  • The issue is directly caused by calling node::Init() with a null pointer for argv
  • The block is guarded by NODE_WITHOUT_NODE_OPTIONS
  • We want to define NODE_WITHOUT_NODE_OPTIONS so the code containing this call is skipped over, but doing so in electron.gyp was unsuccessful

The temporary solution is to add NODE_WITHOUT_NODE_OPTIONS in node.gyp, but we still need to investigate why the .gyp config file definitions don't propagate.

@sethlu @codebytere @nitsakh

@alexeykuzmin

This comment has been minimized.

Show comment
Hide comment
@alexeykuzmin

alexeykuzmin Jun 23, 2018

Contributor

NODE_OPTIONS are ignored starting version 2.0.3. Please use #13402 for a discussion if they shouldn't be ignored.

Electron shouldn't crash because of it anymore. Closed.

Contributor

alexeykuzmin commented Jun 23, 2018

NODE_OPTIONS are ignored starting version 2.0.3. Please use #13402 for a discussion if they shouldn't be ignored.

Electron shouldn't crash because of it anymore. Closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment