Embedding V8 into an Electron native app crashes on macOS

[Zoltan B]

Hi!

I'm running an electron app, that loads native application (using ffi) that renders content into a canvas in electron. This native C++ code has an embedded V8 inside it.

I'm compiling V8 into dynamic libraries (.dylib files) (use_component_build is set to true).

My issue is that the V8 inside Electron seems to clash with my V8 instance (they are not the same version), but only on macOS.

If you look at the call-stack below of the segmentation fault, you can see that it begins in libv8.dylib, but ends up somehow in libnode.dylib which I can't really explain.

Thread 16 Crashed:
0 libnode.dylib 0x0000000108306911 0x107c70000 + 6908177
1 libnode.dylib 0x000000010830609c void v8::internal::LookupIterator::Start<false>() + 60
2 libv8.dylib 0x0000000118bbc354 v8::internal::JSObject::SetOwnPropertyIgnoreAttributes(v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::Name>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes) + 164 (js-objects.cc:3148)
3 libv8.dylib 0x0000000118a9bc06 v8::internal::Genesis::GetThrowTypeErrorIntrinsic() + 118 (handles.h:144)
4 libv8.dylib 0x0000000118a9c13d v8::internal::Genesis::AddRestrictedFunctionProperties(v8::internal::Handle<v8::internal::JSFunction>) + 29 (bootstrapper.cc:1109)
5 libv8.dylib 0x0000000118ab1de5 v8::internal::Genesis::Genesis(v8::internal::Isolate*, v8::internal::MaybeHandle<v8::internal::JSGlobalProxy>, v8::Local<v8::ObjectTemplate>, unsigned long, v8::DeserializeInternalFieldsCallback, v8::MicrotaskQueue*) + 1269 (bootstrapper.cc:5446)
6 libv8.dylib 0x0000000118a9b209 v8::internal::Bootstrapper::CreateEnvironment(v8::internal::MaybeHandle<v8::internal::JSGlobalProxy>, v8::Local<v8::ObjectTemplate>, v8::ExtensionConfiguration*, unsigned long, v8::DeserializeInternalFieldsCallback, v8::MicrotaskQueue*) + 89 (bootstrapper.cc:5374)
7 libv8.dylib 0x00000001188862aa v8::NewContext(v8::Isolate*, v8::ExtensionConfiguration*, v8::MaybeLocal<v8::ObjectTemplate>, v8::MaybeLocal<v8::Value>, unsigned long, v8::DeserializeInternalFieldsCallback, v8::MicrotaskQueue*) + 1722 (api.cc:5697)
8 libv8.dylib 0x00000001188866fa v8::Context::New(v8::Isolate*, v8::ExtensionConfiguration*, v8::MaybeLocal<v8::ObjectTemplate>, v8::MaybeLocal<v8::Value>, v8::DeserializeInternalFieldsCallback, v8::MicrotaskQueue*) + 42 (api.cc:5856)

Is it possible that when libv8.dylib loads the subsequent .dylib files with dlopen() (such as libv8_platform.dylib etc.) that dlopen somehow fetches the V8 symbols inside the libnode.dylib? 

Electron version I'm using: 1.8.8

V8 versions I'm using in my app: 7.2 (I tried it with 7.8 too but with the same results)

Could anyone help me out how to avoid this?

[Ben Noordhuis]

Since you're only seeing this on macOS: is anything linked with -flat_namespace?

[Zoltan B]

Thanks for your reply! No, I'm not using -flat_namespace anywhere (and the default is afaik -twolevel_namespace). I Tried linking to V8 statically, and with 7.8 non-monolith static libs it worked, but I tried again with 7.2 monolithic and it calls into libNode.dylib and crashes. I'll try 7.2 with non-monolithic build but even if it works it seems very unstable.

Is electron built perhaps with flat_namespace? I'm using an old version (1.8, its 2.5 years old).

I'm running out of ideas on how to work around this...

2019. november 22., péntek 3:18:13 UTC+1 időpontban Ben Noordhuis a következőt írta:

[Zoltan B]

Hi! I exported symbols from Electron and my built V8, and indeed the symbols are the same e.g.:

in Electron:

00000000017a31f0 T __ZN2v86Object16SetInternalFieldEiNS_5LocalINS_5ValueEEE

in V8

00000000000267f0 T __ZN2v86Object16SetInternalFieldEiNS_5LocalINS_5ValueEEE

Is there a way to prefix my V8 somehow in the buildconfig to avoid these namespace clashes?

[Zoltan B]

Managed to resolve it by compiling V8 statically into my app, and removing symbols from it using the "Exported symbols file" option. (using strip or objcopy on the already linked app didnt work)