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

[bpasero]

• 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]

Same on

Electron version: 1.8.3
Operating system: Ubuntu 16.04

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

[codebytere]

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]

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

[bpasero]

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]

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

[bpasero]

@codebytere thanks 👍

[SamCosby]

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

[sethlu]

@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]

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]

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.