ark: Release build crashes the R extension immediately (Possibly Intel specific)

[DavisVaughan]

If I download the universal (or x86 specific) daily build, it opens Positron but I immediately get ark failures where Positron states that the extension failed to open. Notably, if I build Positron locally myself, then everything "just works".

In particular I downloaded this build: https://github.com/rstudio/positron/releases/tag/2023.05.0-1413

We think the problem is that I am on an Intel Mac, while the rest of the dev team is on an ARM Mac, and something is wrong related to that.

When I open Positron I see:

And in the R console I see:

Which suggests some linking issue?

---

Kevin had the idea to run otool -L ark on the release build and compare to my local build:

Release:

davis@daviss-mbp-2 release % otool -L ark
ark:
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
    /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

Local:

ark:
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.23.0)
        /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib (compatibility version 4.2.0, current version 4.2.2)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)

Note that /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib is in my local build but not in the release build

Environment variables ``` NVM_INC=/Users/davis/.nvm/versions/node/v16.20.0/include/node RUST_LOG=trace TERM_PROGRAM=vscode NVM_CD_FLAGS=-q TERM=xterm-256color SHELL=/bin/zsh TMPDIR=/var/folders/41/qx_9ygp112nfysdfgxcssgwc0000gn/T/ TERM_PROGRAM_VERSION=1.77.0 ORIGINAL_XDG_CURRENT_DESKTOP=undefined MallocNanoZone=0 RUST_BACKTRACE=1 NVM_DIR=/Users/davis/.nvm USER=davis COMMAND_MODE=unix2003 SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.e9XO1q2v9k/Listeners __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0 VSCODE_AMD_ENTRYPOINT=vs/workbench/api/node/extensionHostProcess ELECTRON_RUN_AS_NODE=1 PATH=/Users/davis/.nvm/versions/node/v16.20.0/bin:/Users/davis/.config/qvm/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/Apple/usr/bin:/Users/davis/.cargo/bin __CFBundleIdentifier=com.rstudio.positron PWD=/Users/davis VSCODE_HANDLES_UNCAUGHT_ERRORS=true R_CLI_NUM_COLORS=256 LANG=en_US.UTF-8 POSITRON_DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib VSCODE_GIT_ASKPASS_EXTRA_ARGS= XPC_FLAGS=0x0 POSITRON_VERSION=2023.04.0 XPC_SERVICE_NAME=0 SHLVL=1 HOME=/Users/davis VSCODE_GIT_ASKPASS_MAIN=/Users/davis/Desktop/Positron.app/Contents/Resources/app/extensions/git/dist/askpass-main.js VSCODE_NLS_CONFIG={"locale":"en-us","osLocale":"en","availableLanguages":{},"_languagePackSupport":true} LOGNAME=davis VSCODE_GIT_IPC_HANDLE=/var/folders/41/qx_9ygp112nfysdfgxcssgwc0000gn/T/vscode-git-c628243e7d.sock VSCODE_IPC_HOOK=/Users/davis/Library/Application Support/Positron/1.77-main.sock VSCODE_CODE_CACHE_PATH=/Users/davis/Library/Application Support/Positron/CachedData/43915e1571f9ed87f48713192ef0a9840323ca2f NVM_BIN=/Users/davis/.nvm/versions/node/v16.20.0/bin R_HOME=/Library/Frameworks/R.framework/Resources VSCODE_PID=52528 VSCODE_GIT_ASKPASS_NODE=/Users/davis/Desktop/Positron.app/Contents/Frameworks/Positron Helper.app/Contents/MacOS/Positron Helper GIT_ASKPASS=/Users/davis/Desktop/Positron.app/Contents/Resources/app/extensions/git/dist/askpass.sh DISPLAY=/private/tmp/com.apple.launchd.oLyTOS7oEG/org.xquartz:0 VSCODE_CWD=/ COLORTERM=truecolor _=/usr/bin/printenv ```

[kevinushey]

I was able to reproduce the issue on my arm64 macOS machine when building through Rosetta; the issue was apparently resolved when I switched to use an x86_64 Rust toolchain. Maybe we need to do that on CI?

[jmcphers]

We are already doing that on CI via RUST_TARGET:

https://github.com/rstudio/positron/blob/3e81de565ee51fbde1c1bbba14f227752aa7e1bd/.github/workflows/build-release-macos.yml#L109-L116

Did you do something more than that locally?

[kevinushey]

Ah, I think I know what the missing piece is -- we need to make sure that the x86_64 build of R is on the PATH, or do something to make sure that it gets selected by the libR-sys build script.

Otherwise, libR-sys tries to link against the arm64 build of R, and that silently fails as we're linking with -undefined dynamic_lookup. Unfortunately, the linker warning is swallowed into the ether (or perhaps it decided to run away from home and live in the woods) so we don't get any indication that the thing we've built isn't functional.

See also: https://github.com/extendr/libR-sys/blob/master/build.rs#L176-L192

The simplest fix might be to set R_HOME while building ark, since libR-sys seems to use that.

[jmcphers]

Oh, that would make sense!

[jmcphers]

There is, in fact, no x86_64 build of R on the macOS build host. This all but confirms Kevin's theory that the problem is that the x86_64 build of ark is not linking to the x86_64 build of R.

I followed Kevin's excellent instructions to set up x86_64 Homebrew on R. Unfortunately, it is only possible to get R 4.3.0 using this method, and we cannot compile against R 4.3.0 due to https://github.com/rstudio/positron/issues/566.

Next I tried installing an older R from CRAN using its .pkg based installer. Unfortunately, installing the .pkg without root access fails without an error, even when the install target is CurrentUserHomeDirectory.

Finally, I tried getting an older R version from another build host we have (la962) that had an older R installed via homebrew a while back (R 4.1). Unfortunately, this did not work either, because a great number of paths inside scripts, dynamic linker paths embedded in executables, etc. referred to the paths on the other host. It's probably not impossible to patch it up to work on our current host, but it's a large task.

We should consider this issue to be blocked on the resolution of https://github.com/rstudio/positron/issues/566. Once that issue is resolved, we can use R 4.3.0 from Homebrew x86_64 along with R_HOME.

[DavisVaughan]

I guess rig doesn't "just work" for this? It may also need sudo, not sure

brew tap r-lib/rig
brew install --cask rig
rig add -a x86_64 release # or rig add -a x86_64 4.2

[jmcphers]

Yes, you need root privilege to install rig (i.e. the second step prompts for the sudo password). :-(

A fifth option might be to build R from source right on the machine...

[kevinushey]

A sixth option: switch from MacinCloud to MacinCloset? Or some other host that gives us a dedicated macOS server instance where we have root access? We've already burned enough engineering time on MacinCloud, and the hacks we keep accumulating do not seem sustainable long-term.

[jmcphers]

My recollection is that the IDE team was working on IT with this since they effectively have the same problem. I'll ping them to get a status on https://github.com/rstudio/rstudio-pro/issues/3068 which was the tracking issue.

[jmcphers]

Okay, now we can use R 4.3 thanks to @romainfrancois.

The next roadblock is that I can't install R on x86_64 Homebrew -- its dependency libx11 is broken. It has to be built from source (since the homebrew prefix differs from the precompiled builds), and compiling it from source results in:

/Users/user229818/homebrew-x86_64/Cellar/xtrans/1.5.0/include/X11/Xtrans/Xtranslcl.c:81:11: fatal er
ror: 'stropts.h' file not found
# include <stropts.h>
          ^~~~~~~~~~~
1 error generated.
make[3]: *** [xim_trans.lo] Error 1

It looks like someone else also reported this issue with libx11 in Homebrew: https://stackoverflow.com/questions/76419113/unable-to-install-libx11-on-macos

and indeed it has been reported upstream in Homebrew: https://github.com/Homebrew/homebrew-core/pull/132483

[DavisVaughan]

I stumbled across this in my googling about this issue https://github.com/maxim-belkin/homebrew-xorg/issues/453

With this patch https://github.com/bluemage650/homebrew-xorg/commit/0153e00ea5c9cfb037215820b660b7d64dcd38c5

May or may not be useful

[jmcphers]

Homebrew finally fixed this yesterday:

https://github.com/Homebrew/homebrew-core/commit/38c920d6de4882a2c1791a5ba84e16154d752aad

so I got our side of the work done and merged. However, I don't have an Intel mac so could not test those bits; I'm marking this as ready for review so someone who does have an Intel mac can take a look.

To test, you need a build > 2023.06.0-1505

[isabelizimm]

I downloaded Positron-2023.06.0-1514-darwin-universal.zip and am seeing this same message on startup. Do I need to update anything on my end re:homebrew, etc?

Oddly, the text under console is just "Use" and the "Start Interpreter" button has no response. I tried to go through the "Start Extension Bisect" and "Restart Extension Host" workflows offered, but that didn't seem to change anything.

[kevinushey]

It looks like our universal build of ark is still missing the link to x86_64 R:

$ otool -L ark
ark (architecture x86_64):
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)
        /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1228.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
        /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)
ark (architecture arm64):
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)
        /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1228.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)
        @rpath/libR.dylib (compatibility version 4.2.0, current version 4.2.2)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
        /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

[DavisVaughan]

In the logs of the release build workflow i see

Installing dependencies in extensions/positron-r...
$ yarn --ignore-engines
yarn install v1.22.19
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
$ ts-node scripts/post-install.ts
yarn run v1.22.19
warning positron-r@0.0.2: The engine "vscode" appears to be invalid.
$ ts-node scripts/compile-kernel.ts
    Finished release [optimized] target(s) in 0.[71](https://github.com/rstudio/positron/actions/runs/5450186302/jobs/9915193782#step:4:72)s
Done in 1.34s.
Done in 4.90s.

where Finished release [optimized] target(s) in 0.[71] seems suspiciously fast for compiling amalthea and its deps.

Could this be using a cached version of libR-sys?

[DavisVaughan]

Interestingly if I download the Universal app from https://github.com/rstudio/positron/releases/tag/2023.06.0-1576 then on my intel mac i see

davis@daviss-mbp-2 bin % otool -L ark                                                                                 
ark:
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)
    /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1228.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
    /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

But if I download the x86 artifact from the same commit hash here https://github.com/rstudio/positron/actions/runs/5450186302

then I see

davis@daviss-mbp-2 bin % otool -L ark                                                                                                          
ark:
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1953.255.0)
    /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1228.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)
    @rpath/libR.dylib (compatibility version 4.3.0, current version 4.3.1)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
    /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

But even with the x86 specific build I see that "extension host terminated unexpectedly" which makes me think maybe that is separate

[DavisVaughan]

I managed to reproduce Extension host terminated 3 times... with the positron-r and positron-python extensions disabled.

I then tried removing the jupyter-adapter extension and then it goes away, which tells me that we also have issues here.

In the developer tools, I saw this in the release builds, but struggled to get a backtrace for it

After much effort, I have managed to actually reproduce this in a dev build on Positron on my ARM mac by running yarn in an x86_64 zsh shell with an x86_64 version of node installed, and then hitting |> Positron. I believe that rebuilt all of the node modules with x86_64.

Then I was able to set a breakpoint in Positron after the extension host started up, but before the problematic extension was started, and from there I used Help -> Open Process Explorer to figure out which PID went with the extension host.

Once I had the PID, I started a second shell with lldb attached to that PID, then hit "continue" in Positron. Once it crashed, I finally got more details about that backtrace

So this tells me it is zeromq's random_open() function that is causing the error - and if we look into it, we see that that is calling sodium_init() https://github.com/zeromq/libzmq/blob/ecc63d0d3b0e1a62c90b58b1ccdb5ac16cb2400a/src/random.cpp#L39-L63

This checks out, because jupyter-adapter is where our version of zeromq lives.

zeromq itself is built with x86_64 (I checked), but we use a custom version of it that tries to statically link to a local copy of libsodium. https://github.com/zeromq/zeromq.js/compare/master...kevinushey:zeromq.js:master

It seems that the version of libsodium it finds on my machine is ARM based, causing the missing symbol error.

I imagine this is also happening on CI, so it seems like we need a way to tell zeromq to link to a version of libsodium built with the right architecture, but I'm not sure how to do that.

Full backtrace ``` (lldb) bt * thread #1, name = 'CrUtilityMain', queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x0000000202933c42 dyld`__abort_with_payload + 10 frame #1: 0x000000020294dfd7 dyld`abort_with_payload_wrapper_internal + 82 frame #2: 0x000000020294e009 dyld`abort_with_payload + 9 frame #3: 0x00000002028d28f0 dyld`dyld4::halt(char const*) + 375 frame #4: 0x000000020290423e dyld`dyld4::APIs::_dyld_missing_symbol_abort() + 34 frame #5: 0x000000016a20d66c zeromq.node`zmq::random_open() + 12 frame #6: 0x000000016a1ed588 zeromq.node`zmq::ctx_t::ctx_t() + 328 frame #7: 0x000000016a231b81 zeromq.node`zmq_ctx_new + 49 frame #8: 0x000000016a1cac89 zeromq.node`zmq::Module::Global::Global(this=) at module.cc:69:21 [opt] frame #9: 0x000000016a1cae58 zeromq.node`zmq::Module::Global::Instance() [inlined] zmq::Module::Global::Global(this=0x00007fb22c522c38) at module.cc:68:26 [opt] frame #10: 0x000000016a1cae50 zeromq.node`zmq::Module::Global::Instance() [inlined] std::__1::__shared_ptr_emplace >::__shared_ptr_emplace[abi:v15006]<>(this=0x00007fb22c522c20, __a=) at shared_ptr.h:294:37 [opt] frame #11: 0x000000016a1cae38 zeromq.node`zmq::Module::Global::Instance() [inlined] std::__1::__shared_ptr_emplace >::__shared_ptr_emplace[abi:v15006]<>(this=0x00007fb22c522c20, __a=) at shared_ptr.h:288:5 [opt] frame #12: 0x000000016a1cae38 zeromq.node`zmq::Module::Global::Instance() [inlined] std::__1::shared_ptr std::__1::allocate_shared[abi:v15006], void>(__a=) at shared_ptr.h:953:55 [opt] frame #13: 0x000000016a1cae2b zeromq.node`zmq::Module::Global::Instance() [inlined] std::__1::shared_ptr std::__1::make_shared[abi:v15006]() at shared_ptr.h:962:12 [opt] frame #14: 0x000000016a1cae2b zeromq.node`zmq::Module::Global::Instance() at module.cc:90:21 [opt] frame #15: 0x000000016a1cafec zeromq.node`zmq::Module::Module(this=0x00007fb22c522e60, exports=Object @ 0x0000000308eb1b70) at module.h:92:29 [opt] frame #16: 0x000000016a1cc76b zeromq.node`::napi_register_module_v1(napi_env, napi_value) [inlined] zmq::Module::Module(this=0x00007fb22c522e60, exports=Object @ 0x0000600000c3e160) at module.cc:95:64 [opt] frame #17: 0x000000016a1cc75d zeromq.node`::napi_register_module_v1(env=0x00007fb22c522d30, exports=0x00007fb22b836c30) at module.cc:112:23 [opt] frame #18: 0x000000011b21e59d Electron Framework`node::AsyncResource::CallbackScope::CallbackScope(node::AsyncResource*) + 3053 frame #19: 0x000000011b22fe37 Electron Framework`node::binding::get_linked_module(char const*) + 3751 frame #20: 0x000000011b1f6fd1 Electron Framework`node::EmitAsyncDestroy(node::Environment*, node::async_context) + 280353 frame #21: 0x000000011b22ea25 Electron Framework`node_module_register + 2533 frame #22: 0x00000001154f1374 Electron Framework`v8::internal::Accessors::MakeAccessor(v8::internal::Isolate*, v8::internal::Handle, void (*)(v8::Local, v8::PropertyCallbackInfo const&), void (*)(v8::Local, v8::Local, v8::PropertyCallbackInfo const&)) + 12772 frame #23: 0x000001121ff176f8 frame #24: 0x000001120005c44e frame #25: 0x000001121fe8baac frame #26: 0x000001120005c44e frame #27: 0x000001120005642c frame #28: 0x000001120003559a frame #29: 0x00000112000206f3 frame #30: 0x0000011200078bb1 frame #31: 0x000001120007a74c frame #32: 0x0000011200012bb9 frame #33: 0x000001120001d01c frame #34: 0x000001120001d292 frame #35: 0x000001121fe8baac frame #36: 0x000001121fe8baac frame #37: 0x000001120005ac30 frame #38: 0x00000112000616b7 frame #39: 0x000001120005642c frame #40: 0x000001120003559a frame #41: 0x00000112000206f3 frame #42: 0x0000011200078bb1 frame #43: 0x000001120007a74c frame #44: 0x0000011200012bb9 frame #45: 0x000001120001d01c frame #46: 0x000001120001d292 frame #47: 0x000001121fe8baac frame #48: 0x000001120005ac30 frame #49: 0x00000112000616b7 frame #50: 0x000001120005642c frame #51: 0x000001120003559a frame #52: 0x00000112000206f3 frame #53: 0x0000011200078bb1 frame #54: 0x000001120007a74c frame #55: 0x0000011200012bb9 frame #56: 0x000001120001d01c frame #57: 0x000001120001d292 frame #58: 0x000001121fe8baac frame #59: 0x000001120005ac30 frame #60: 0x00000112000616b7 frame #61: 0x000001120005642c frame #62: 0x000001120003559a frame #63: 0x00000112000206f3 frame #64: 0x0000011200078bb1 frame #65: 0x000001120007a74c frame #66: 0x0000011200012bb9 frame #67: 0x000001120001d01c frame #68: 0x000001120001d292 frame #69: 0x000001121fe8baac frame #70: 0x000001120005ac30 frame #71: 0x00000112000616b7 frame #72: 0x000001120005642c frame #73: 0x000001120003559a frame #74: 0x00000112000206f3 frame #75: 0x0000011200078bb1 frame #76: 0x000001120007a74c frame #77: 0x0000011200012bb9 frame #78: 0x000001120001d01c frame #79: 0x000001120001d292 frame #80: 0x000001121fe8baac frame #81: 0x000001120005ac30 frame #82: 0x00000112000616b7 frame #83: 0x000001120005642c frame #84: 0x000001120003559a frame #85: 0x00000112000206f3 frame #86: 0x0000011200078bb1 frame #87: 0x000001120007a74c frame #88: 0x0000011200012bb9 frame #89: 0x000001120001d01c frame #90: 0x000001120001d292 frame #91: 0x000001121fe8baac frame #92: 0x000001120005ac30 frame #93: 0x00000112000616b7 frame #94: 0x000001120005642c frame #95: 0x000001120003559a frame #96: 0x00000112000206f3 frame #97: 0x0000011200078bb1 frame #98: 0x000001120007a74c frame #99: 0x0000011200012bb9 frame #100: 0x000001120001d01c frame #101: 0x000001120001d292 frame #102: 0x000001121fe8baac frame #103: 0x000001120005ac30 frame #104: 0x00000112000616b7 frame #105: 0x000001120005642c frame #106: 0x000001120003559a frame #107: 0x00000112000206f3 frame #108: 0x0000011200078bb1 frame #109: 0x000001120007a74c frame #110: 0x0000011200012bb9 frame #111: 0x000001120001d01c frame #112: 0x000001120001d292 frame #113: 0x000001121fe8baac frame #114: 0x000001120005ac30 frame #115: 0x00000112000616b7 frame #116: 0x000001120005642c frame #117: 0x000001120003559a frame #118: 0x00000112000206f3 frame #119: 0x0000011200078bb1 frame #120: 0x000001120007a74c frame #121: 0x0000011200012bb9 frame #122: 0x000001120001d01c frame #123: 0x000001120001d292 frame #124: 0x000001121fe8baac frame #125: 0x000001120005ac30 frame #126: 0x00000112000616b7 frame #127: 0x000001120005642c frame #128: 0x000001120003559a frame #129: 0x00000112000206f3 frame #130: 0x0000011200078bb1 frame #131: 0x000001120007a74c frame #132: 0x0000011200012bb9 frame #133: 0x000001120001d01c frame #134: 0x000001120001d292 frame #135: 0x0000011200032291 frame #136: 0x000001121fe8baac frame #137: 0x000001121fec5138 frame #138: 0x000001121ff713f1 frame #139: 0x000001121feb416d frame #140: 0x000001121fe8a007 frame #141: 0x00000001155cc507 Electron Framework`v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle, v8::internal::Handle, int, v8::internal::Handle*) + 6871 frame #142: 0x00000001155cd05a Electron Framework`v8::internal::Execution::TryCallScript(v8::internal::Isolate*, v8::internal::Handle, v8::internal::Handle, v8::internal::Handle, v8::internal::Execution::MessageHandling, v8::internal::MaybeHandle*, bool) + 394 frame #143: 0x00000001155cd1c9 Electron Framework`v8::internal::Execution::TryCall(v8::internal::Isolate*, v8::internal::Handle, v8::internal::Handle, int, v8::internal::Handle*, v8::internal::Execution::MessageHandling, v8::internal::MaybeHandle*, bool) + 217 frame #144: 0x00000001155ff49e Electron Framework`v8::internal::MicrotaskQueue::PerformCheckpointInternal(v8::Isolate*) + 286 frame #145: 0x000000011b1ad3ce Electron Framework`node::CallbackScope::~CallbackScope() + 846 frame #146: 0x000000011b1ad0b1 Electron Framework`node::CallbackScope::~CallbackScope() + 49 frame #147: 0x00000001143a7f92 Electron Framework`v8::CodeEvent::GetComment() + 306 frame #148: 0x00000001176f985a Electron Framework`node::AsyncResource::get_async_id() const + 9408874 frame #149: 0x000000011770f077 Electron Framework`node::AsyncResource::get_async_id() const + 9496967 frame #150: 0x00000001176b06fe Electron Framework`node::AsyncResource::get_async_id() const + 9109518 frame #151: 0x000000011770fe2a Electron Framework`node::AsyncResource::get_async_id() const + 9500474 frame #152: 0x00000001176d2531 Electron Framework`node::AsyncResource::get_async_id() const + 9248321 frame #153: 0x0000000117081cd5 Electron Framework`node::AsyncResource::get_async_id() const + 2627045 frame #154: 0x00000001145c1c21 Electron Framework`v8::internal::compiler::BasicBlock::set_loop_header(v8::internal::compiler::BasicBlock*) + 17601 frame #155: 0x00000001145c27c1 Electron Framework`v8::internal::compiler::BasicBlock::set_loop_header(v8::internal::compiler::BasicBlock*) + 20577 frame #156: 0x00000001145c0d04 Electron Framework`v8::internal::compiler::BasicBlock::set_loop_header(v8::internal::compiler::BasicBlock*) + 13732 frame #157: 0x00000001145c1367 Electron Framework`v8::internal::compiler::BasicBlock::set_loop_header(v8::internal::compiler::BasicBlock*) + 15367 frame #158: 0x00000001142a29bb Electron Framework`ElectronMain + 155 frame #159: 0x00000001024f2b45 Positron Helper (Plugin)`_mh_execute_header + 2885 frame #160: 0x00000002028ce41f dyld`start + 1903 ```

[DavisVaughan]

I believe I have all of this fixed in https://github.com/rstudio/positron/pull/820. As seen in https://github.com/rstudio/positron/pull/820#issuecomment-1631388275, the release builds that can be generated from this PR successfully start on an Intel Mac!

[jmcphers]

@isabelizimm Could you review this since you have an Intel mac?

[jennybc]

FWIW I have resurrected my 2015 MacBook Pro, running macOS Monterey (12.6.7), with the CRAN installation of R 4.3.1, and I successfully installed and launched the artifact positron-darwin-universal-archive from https://github.com/rstudio/positron/actions/runs/5523651576. I can interact with the R interpreter.

[jmcphers]

OK, good enough for us to close this. Thanks @jennybc!