Repository navigation
Support for Electron 9 #898
Description
Environment
Tech stack:
- nan 2.14.0
- electron 9.1.2
- cmake-js 6.0.0
- cmake 3.17.0
Environment:
- Mac OS 10.15.5 (Reproduced on Windows 10 as well)
Premise
We're trying to update from Electron 5 to 9 and we have a native module that is causing issues. The module builds successfully with the following setup:
// Package.json
{
"scripts": {
"build": "cmake-js build -l verbose",
},
"cmake-js": {
"runtime": "electron",
"runtimeVersion": "9.1.2"
}
}But when our Electron app launches it crashes after trying to access the native module with the following crash report:
Process: Electron [47212]
Path: /Users/USER/*/Electron.app/Contents/MacOS/Electron
Identifier: com.github.Electron
Version: 9.1.2 (9.1.2)
Code Type: X86-64 (Native)
Parent Process: ??? [47206]
Responsible: iTerm2 [80766]
User ID: 502
Date/Time: 2020-08-11 11:12:28.213 -0400
OS Version: Mac OS X 10.15.5 (19F101)
Report Version: 12
Bridge OS Version: 4.5 (17P5300)
...
Crashed Thread: 0 CrBrowserMain Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [47212]
Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread
0 license.node 0x0000000113c57a9f Nan::imp::FunctionCallbackWrapper(v8::FunctionCallbackInfo<v8::Value> const&) + 31
1 com.github.Electron.framework 0x00000001070a86df v8::internal::Accessors::MakeAccessor(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Name>, void (*)(v8::Local<v8::Name>, v8::PropertyCallbackInfo<v8::Value> const&), void (*)(v8::Local<v8::Name>, v8::Local<v8::Value>, v8::PropertyCallbackInfo<v8::Boolean> const&)) + 16815
2 com.github.Electron.framework 0x00000001070a7c01 v8::internal::Accessors::MakeAccessor(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Name>, void (*)(v8::Local<v8::Name>, v8::PropertyCallbackInfo<v8::Value> const&), void (*)(v8::Local<v8::Name>, v8::Local<v8::Value>, v8::PropertyCallbackInfo<v8::Boolean> const&)) + 14033
3 com.github.Electron.framework 0x00000001070a7292 v8::internal::Accessors::MakeAccessor(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Name>, void (*)(v8::Local<v8::Name>, v8::PropertyCallbackInfo<v8::Value> const&), void (*)(v8::Local<v8::Name>, v8::Local<v8::Value>, v8::PropertyCallbackInfo<v8::Boolean> const&)) + 11618
4 com.github.Electron.framework 0x0000000107ada558 v8::internal::SetupIsolateDelegate::SetupHeap(v8::internal::Heap*) + 484152
...
After further testing we realized the nan's TravisCI config file only included Electron versions up to 8.2.3. After testing our app with this version everything ran flawlessly. So basically we're wondering what could cause this issue. Could anyone provide insight or perhaps confirm this is a nan issue?
Thanks
Activity
danielo-unity3d commentedon Aug 12, 2020
Stack trace on Windows is:
Symbols downloaded from here, otherwise we would only see the 1st four frames...
mastergberry commentedon Aug 20, 2020
I ran into this same problem with my application. This needs to be fixed, but there is a workaround (not ideal) for Windows currently: Disable inline functions with
/Odor/Ob0- Reference: https://docs.microsoft.com/en-us/cpp/build/reference/ob-inline-function-expansion?view=vs-2019I have not had success with disabling similar stuff on macOS such as
-O0or-fno-inline-functions...so we really need a proper fix for these bad memory offsets that appear to be occurring with Electron 9.mastergberry commentedon Aug 20, 2020
I just spent some time testing different electron versions, and it does appear that this problem is not present on electron 8.5.0, but is still present on electron 10.
Also not 100% sure if this is a nan problem, or a core v8/chromium/electron problem.
mastergberry commentedon Aug 21, 2020
I found this ticket: wilix-team/iohook#241 which reports the same problem. Sounds like some compiler flag in cmake is causing it to crash (probably still due to bad code).
mastergberry commentedon Nov 4, 2020
So just a followup here, I have migrated a sample project & my actual project from
nan->node-addon-apiand now I am no longer facing these issues above. It seems that there is some conflict betweennanandelectronv9+...but I'm not sure nan is going to be getting long term support anymore.I think the general idea is people should be moving off of
nanand move towardsnode-addon-api...since this software is no longer receiving frequent updates.