vscode: vscode 1.78+ silently fails to start with electron 19 on ppc64le, segfaults with electron 22

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: e5f61433b58084dcf312d9845f090ff2efc31b54 or later
• OS Version: Gentoo Linux ppc64le (4K page size)

Steps to Reproduce:

1. Install electron 22 and vscode git from the pf4public overlay on a ppc64le system.
2. Start code-oss:

niko@talos2 ~ $ code-oss
Warning: 'app' is not in the list of known options, but still passed to Electron/Chromium.
Warning: 'ozone-platform-hint' is not in the list of known options, but still passed to Electron/Chromium.
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.

niko@talos2 ~ $ ps aux | grep code-oss
niko     1085466  0.0  0.0   6964  2304 pts/4    S+   10:58   0:00 grep --colour=auto code-oss

1. See backtrace:

[169424.541820] electron[942219]: segfault (11) at 260cd4b6fd48 nip 3fff9b9883f4 lr 134b9b058 code 1 in spdlog.node[3fff9b960000+74000]
[169424.541842] electron[942219]: code: e87c0020 3b7c0020 f8010010 f821ff91 7c3f0b78 f8410018 786a07c4 e92d8ff0 
[169424.541847] electron[942219]: code: f93f0038 39200000 8123ffff 7d2a4a14 <a1290007> 2c090410 41820010 3929fbdf

talos2 ~ # coredumpctl gdb 942219
           PID: 942219 (electron)
           UID: 1000 (niko)
           GID: 1000 (niko)
        Signal: 11 (SEGV)
     Timestamp: Wed 2023-05-17 09:39:34 CEST (22s ago)
  Command Line: $'/usr/lib64/electron-22/electron --app=/usr/lib64/vscode --ozone-platform-hint=auto --enable-features=WaylandWindowDecorations'
    Executable: /usr/lib64/electron-22/electron
 Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-d10cc436-81bc-4378-b456-18da74bb049a.scope
          Unit: user@1000.service
     User Unit: vte-spawn-d10cc436-81bc-4378-b456-18da74bb049a.scope
         Slice: user-1000.slice
     Owner UID: 1000 (niko)
       Boot ID: d1e3185941124a8e94148ff9cbdac071
    Machine ID: b3e834569b8ff461391f5ac061feb773
      Hostname: talos2
       Storage: /var/lib/systemd/coredump/core.electron.1000.d1e3185941124a8e94148ff9cbdac071.942219.1684309174000000.zst (present)
  Size on Disk: 6.3M
       Message: Process 942219 (electron) of user 1000 dumped core.

GNU gdb (Gentoo 13.1.90_p20230325 vanilla) 13.1.90.20230325-git
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64le-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib64/electron-22/electron...

warning: Can't open file /dev/shm/.org.chromium.Chromium.4IL4ug (deleted) during file-backed mapping note processing

warning: Can't open file /dev/shm/.org.chromium.Chromium.aOpNhz (deleted) during file-backed mapping note processing
[New LWP 942219]
[New LWP 942226]
[New LWP 942231]
[New LWP 942229]
[New LWP 942232]
[New LWP 942246]
[New LWP 942234]
[New LWP 942228]
[New LWP 942236]
[New LWP 942245]
[New LWP 942252]
[New LWP 942220]
[New LWP 942227]
[New LWP 942235]
[New LWP 942247]
[New LWP 942230]
[New LWP 942238]
[New LWP 942250]
[New LWP 942240]
[New LWP 942241]
[New LWP 942257]
[New LWP 942255]
[New LWP 942310]
[New LWP 942237]
[New LWP 942243]
[New LWP 942244]
[New LWP 942256]
[New LWP 942249]
[New LWP 942251]
[New LWP 942254]
[New LWP 942233]
[New LWP 942239]
[New LWP 942248]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
Core was generated by `/usr/lib64/electron-22/electron --app=/usr/lib64/vscode --ozone-platform-hint=a'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  v8::internal::Internals::CanHaveInternalField (instance_type=<error reading variable: Cannot access memory at address 0x260cd4b6fd48>) at /usr/include/electron-22/node/v8-internal.h:662
662	    return instance_type == kJSSpecialApiObjectType ||
[Current thread is 1 (Thread 0x3fffb5367040 (LWP 942219))]
(gdb) backtrace
#0  v8::internal::Internals::CanHaveInternalField(int) (instance_type=<error reading variable: Cannot access memory at address 0x260cd4b6fd48>) at /usr/include/electron-22/node/v8-internal.h:662
#1  v8::Object::GetInternalField(int) (index=1, this=0x3fffeea4aa00) at /usr/include/electron-22/node/v8-object.h:714
#2  Nan::imp::FunctionCallbackWrapper(v8::FunctionCallbackInfo<v8::Value> const&) (info=...) at ../../../nan/nan_callbacks_12_inl.h:173
#3  0x0000000134b9b058 in v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) (this=0x3fffeea4a9c8, handler=...) at ../../v8/src/api/api-arguments-inl.h:146
#4  v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, unsigned long*, int)
    (isolate=0xbe401ec0000, new_target=..., fun_data=..., receiver=..., argv=<optimized out>, argc=<optimized out>) at ../../v8/src/builtins/builtins-api.cc:112
#5  0x0000000134b9a388 in v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) (args=..., isolate=0xbe401ec0000) at ../../v8/src/builtins/builtins-api.cc:143
#6  v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) (args_length=6, args_object=<optimized out>, isolate=0xbe401ec0000) at ../../v8/src/builtins/builtins-api.cc:130
#7  0x0000000135b7c600 in Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit ()
(gdb) info threads
  Id   Target Id                          Frame 
* 1    Thread 0x3fffb5367040 (LWP 942219) v8::internal::Internals::CanHaveInternalField (instance_type=<error reading variable: Cannot access memory at address 0x260cd4b6fd48>) at /usr/include/electron-22/node/v8-internal.h:662
  2    Thread 0x3fffaabfd980 (LWP 942226) 0x00003fffb02486d4 in wait4 () from /usr/lib64/libc.so.6
  3    Thread 0x3fffa83f8980 (LWP 942231) 0x00003fffb0241624 in clock_nanosleep () from /usr/lib64/libc.so.6
  4    Thread 0x3fffa93fa980 (LWP 942229) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  5    Thread 0x3fffa7bf7980 (LWP 942232) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  6    Thread 0x3fffa19fd980 (LWP 942246) 0x00003fffb0241624 in clock_nanosleep () from /usr/lib64/libc.so.6
  7    Thread 0x3fffa6b53980 (LWP 942234) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  8    Thread 0x3fffa9bfb980 (LWP 942228) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  9    Thread 0x3fffa5b51980 (LWP 942236) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  10   Thread 0x3fffa21fe980 (LWP 942245) 0x00003fffb027ff14 in poll () from /usr/lib64/libc.so.6
  11   Thread 0x3fff9e9f7980 (LWP 942252) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  12   Thread 0x3fffab3fe980 (LWP 942220) 0x00003fffb027ff14 in poll () from /usr/lib64/libc.so.6
  13   Thread 0x3fffaa3fc980 (LWP 942227) 0x00003fffb0293c94 in epoll_wait () from /usr/lib64/libc.so.6
  14   Thread 0x3fffa6352980 (LWP 942235) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  15   Thread 0x3fffa11fc980 (LWP 942247) 0x00003fffb027ff14 in poll () from /usr/lib64/libc.so.6
  16   Thread 0x3fffa8bf9980 (LWP 942230) 0x00003fffb0293c94 in epoll_wait () from /usr/lib64/libc.so.6
  17   Thread 0x3fffa517e980 (LWP 942238) 0x00003fffb0289720 in syscall () from /usr/lib64/libc.so.6
  18   Thread 0x3fff9f9f9980 (LWP 942250) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  19   Thread 0x3fffa417c980 (LWP 942240) 0x00003fffb027ff14 in poll () from /usr/lib64/libc.so.6
  20   Thread 0x3fffa397b980 (LWP 942241) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  21   Thread 0x3fff9c9f3980 (LWP 942257) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  22   Thread 0x3fff9d9f5980 (LWP 942255) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  23   Thread 0x3fff9c1f2980 (LWP 942310) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  24   Thread 0x3fffab778980 (LWP 942237) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  25   Thread 0x3fffa317a980 (LWP 942243) 0x00003fffb0293c94 in epoll_wait () from /usr/lib64/libc.so.6
  26   Thread 0x3fffab72e980 (LWP 942244) 0x00003fffb0279d74 in read () from /usr/lib64/libc.so.6
  27   Thread 0x3fff9d1f4980 (LWP 942256) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  28   Thread 0x3fffa01fa980 (LWP 942249) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  29   Thread 0x3fff9f1f8980 (LWP 942251) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  30   Thread 0x3fff9e1f6980 (LWP 942254) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
  31   Thread 0x3fffa7354980 (LWP 942233) 0x00003fffb0293c94 in epoll_wait () from /usr/lib64/libc.so.6
  32   Thread 0x3fffa497d980 (LWP 942239) 0x00003fffb027ff14 in poll () from /usr/lib64/libc.so.6
  33   Thread 0x3fffa09fb980 (LWP 942248) 0x00003fffb01de5c4 in ?? () from /usr/lib64/libc.so.6
(gdb) quit

/usr/include/electron-22/node/v8-internal.h:662 is the return statement:

    // Check for IsJSObject() || IsJSSpecialApiObject() || IsJSApiObject()
    return instance_type == kJSSpecialApiObjectType ||
           // inlined version of base::IsInRange
           (static_cast<unsigned>(static_cast<unsigned>(instance_type) -
                                  static_cast<unsigned>(kJSObjectType)) <=
            static_cast<unsigned>(kLastJSApiObjectType - kJSObjectType));
  }

talos2 ~ # find /var/tmp/portage/dev-util/electron-22.3.9/work/ | grep "v8-internal.h"
/var/tmp/portage/dev-util/electron-22.3.9/work/chromium-108.0.5359.125/out/Release/gen/node_headers/include/node/v8-internal.h
/var/tmp/portage/dev-util/electron-22.3.9/work/chromium-108.0.5359.125/v8/include/v8-internal.h
/var/tmp/portage/dev-util/electron-22.3.9/work/node-v16.17.1/deps/v8/include/v8-internal.h

/usr/include/electron-22/node/v8-object.h:714 is the if statement:

#ifndef V8_ENABLE_CHECKS
  using A = internal::Address;
  using I = internal::Internals;
  A obj = *reinterpret_cast<A*>(this);
  // Fast path: If the object is a plain JSObject, which is the common case, we
  // know where to find the internal fields and can return the value directly.
  int instance_type = I::GetInstanceType(obj);
  if (I::CanHaveInternalField(instance_type)) {
    int offset = I::kJSObjectHeaderSize + (I::kEmbedderDataSlotSize * index);
    A value = I::ReadRawField<A>(obj, offset);

talos2 ~ # find /var/tmp/portage/dev-util/electron-22.3.9/work/ | grep "v8-object.h"
/var/tmp/portage/dev-util/electron-22.3.9/work/chromium-108.0.5359.125/out/Release/gen/node_headers/include/node/v8-object.h
/var/tmp/portage/dev-util/electron-22.3.9/work/chromium-108.0.5359.125/v8/include/v8-object.h

I am well aware that ppc64le is not a supported architecture, but I am currently maintaining the ppc64le electron and vscode ebuilds for Gentoo and chances are there might be some issue in the vscode codebase which somehow gets triggered only on ppc. In fact electron by itself does start succesfully and it works with other applications (like flipper) as well. With vscode (e5f61433b58084dcf312d9845f090ff2efc31b54 or later) it silently fails to start with no error messages in the stdout/stderr. Electron 21, 22, 23 and 24 segfault, while electron 19 doesn’t (but still doesn’t start and there are still no errors in the stdout/stderr). Please note that while e5f6143 does indeed make use of electron 22 our vscode ebuild manually targets electron 19-…-24 via use flags. The fact that e5f6143 with the electron-19 use flag does result in vscode failing to start (while the commit before works) means that it might be some other change at work. Apart from the electron version bump I see many other changes in that commit, but I’m unsure which one might be the culprit.

I will gladly appreciate any input to help me debug this.

@PF4Public @madscientist159