Stablize apple silicon exploration builds
deepak1556 opened this issue · comments
Umbrella issue:
- Create self-hosted agent with DTK for ci testing #106773
- Ensure automatic updates work #106771
- Crash in v8 when loading oniguruma wasm module #106770 (comment)
- Use arm64 binaries of ripgrep
- Add downloads links to website https://github.com/microsoft/vscode-website/pull/901
- Publish remote server bits for mac arm64 microsoft/vscode-remote-release#4069
- Publish mac arm64 MS electron builds (thanks to @alexeykuzmin)
- Update download links in the website from exploration to insiders https://github.com/microsoft/vscode-website/pull/912
- Provide notification to use arm builds when running on Rosetta
- Crash on startup #113852
Build to use: https://code.visualstudio.com/insiders/
Any other issues that might come in from testing, should be added to the above list.
Operating system: Mac OS X
11.0.1 20B5012d
CPU: arm64
8 CPUs
GPU: UNKNOWN
Crash reason: EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE
Crash address: 0x7004ee54e0
Process uptime: 3 seconds
Thread 21 (crashed)
0 libsystem_platform.dylib + 0x3970
x0 = 0x0000007004ee54e0 x1 = 0x00000001368ab840
x2 = 0x00000000000078af x3 = 0x0000007004ee5500
x4 = 0x0000000000000000 x5 = 0x0000000000000020
x6 = 0x0000000000000000 x7 = 0x0000000000000000
x8 = 0x00000000000078cf x9 = 0x0000000000000002
x10 = 0x0000000000000000 x11 = 0x0000000000000000
x12 = 0x00000000000078e0 x13 = 0x0000000000000002
x14 = 0x00000000000002c1 x15 = 0x00000000000060d7
x16 = 0x00000001841d4930 x17 = 0x000000012660cb00
x18 = 0x0000000000000000 x19 = 0x0000000000000295
x20 = 0x0000000000000002 x21 = 0x00000001368b356b
x22 = 0x0000000126709f80 x23 = 0x00000000000078e0
x24 = 0x00000000000078cf x25 = 0x0000007004ee54e0
x26 = 0x000000010a06ea78 x27 = 0x000000018419e970
x28 = 0x00000000000078cf fp = 0x0000000176db64b0
lr = 0x0000000103607614 sp = 0x0000000176db6360
pc = 0x00000001841d4970
Found by: given as instruction pointer in context
1 Electron Framework!v8::internal::wasm::NativeModule::AddCodeWithCodeSpace(int, v8::internal::CodeDesc const&, int, int, v8::internal::Vector<unsigned char const>, v8::internal::Vector<unsigned char const>, v8::internal::wasm::WasmCode::Kind, v8::internal::wasm::ExecutionTier, v8::internal::wasm::ForDebugging, v8::internal::Vector<unsigned char>, v8::internal::wasm::NativeModule::JumpTablesRef const&) [wasm-code-manager.cc : 1036 + 0x4]
fp = 0x0000000176db6560 lr = 0x0000000103608364
sp = 0x0000000176db64c0 pc = 0x0000000103607614
Found by: previous frame's frame pointer
2 Electron Framework!v8::internal::wasm::NativeModule::AddCompiledCode(v8::internal::Vector<v8::internal::wasm::WasmCompilationResult>) [wasm-code-manager.cc : 1902 + 0x20]
fp = 0x0000000176db6700 lr = 0x00000001035f9238
sp = 0x0000000176db6570 pc = 0x0000000103608364
Found by: previous frame's frame pointer
3 Electron Framework!v8::internal::wasm::(anonymous namespace)::ExecuteCompilationUnits(std::__1::shared_ptr<v8::internal::wasm::(anonymous namespace)::BackgroundCompileToken> const&, v8::internal::Counters*, v8::JobDelegate*, v8::internal::wasm::(anonymous namespace)::CompileBaselineOnly)::$_5::operator()(v8::internal::wasm::(anonymous namespace)::BackgroundCompileScope*) const [module-compiler.cc : 1312 + 0x4]
fp = 0x0000000176db6910 lr = 0x00000001035f8404
sp = 0x0000000176db6710 pc = 0x00000001035f9238
Found by: previous frame's frame pointer
4 Electron Framework!v8::internal::wasm::(anonymous namespace)::ExecuteCompilationUnits(std::__1::shared_ptr<v8::internal::wasm::(anonymous namespace)::BackgroundCompileToken> const&, v8::internal::Counters*, v8::JobDelegate*, v8::internal::wasm::(anonymous namespace)::CompileBaselineOnly) [module-compiler.cc : 1367 + 0x8]
fp = 0x0000000176db6930 lr = 0x00000001035fbd60
sp = 0x0000000176db6920 pc = 0x00000001035f8404
Found by: previous frame's frame pointer
5 Electron Framework!v8::internal::wasm::(anonymous namespace)::BackgroundCompileJob::Run(v8::JobDelegate*) [module-compiler.cc : 1658 + 0x4]
fp = 0x0000000176db6950 lr = 0x0000000104c005e0
sp = 0x0000000176db6940 pc = 0x00000001035fbd60
Found by: previous frame's frame pointer
6 Electron Framework!base::internal::Invoker<base::internal::BindState<gin::V8Platform::PostJob(v8::TaskPriority, std::__1::unique_ptr<v8::JobTask, std::__1::default_delete<v8::JobTask> >)::$_0, base::internal::UnretainedWrapper<v8::JobTask> >, void (base::JobDelegate*)>::Run(base::internal::BindStateBase*, base::JobDelegate*) [v8_platform.cc : 508 + 0xc]
fp = 0x0000000176db6990 lr = 0x0000000103eb9120
sp = 0x0000000176db6960 pc = 0x0000000104c005e0
Found by: previous frame's frame pointer
7 Electron Framework!base::internal::Invoker<base::internal::BindState<base::internal::JobTaskSource::JobTaskSource(base::Location const&, base::TaskTraits const&, base::RepeatingCallback<void (base::JobDelegate*)>, base::RepeatingCallback<unsigned long (unsigned long)>, base::internal::PooledTaskRunnerDelegate*)::$_0, base::internal::UnretainedWrapper<base::internal::JobTaskSource> >, void ()>::Run(base::internal::BindStateBase*) [callback.h : 135 + 0x4]
fp = 0x0000000176db6a70 lr = 0x0000000103ea7b98
sp = 0x0000000176db69a0 pc = 0x0000000103eb9120
Found by: previous frame's frame pointer
8 Electron Framework!base::TaskAnnotator::RunTask(char const*, base::PendingTask*) [callback.h : 100 + 0x0]
fp = 0x0000000176db6a80 lr = 0x0000000103ebe548
sp = 0x0000000176db6a80 pc = 0x0000000103ea7b98
Found by: previous frame's frame pointer
9 Electron Framework!base::internal::TaskTracker::RunSkipOnShutdown(base::internal::Task*) [task_tracker.cc : 768 + 0x8]
fp = 0x0000000176db6c00 lr = 0x0000000103ebdf74
sp = 0x0000000176db6a90 pc = 0x0000000103ebe548
Found by: previous frame's frame pointer
10 Electron Framework!base::internal::TaskTracker::RunTask(base::internal::Task, base::internal::TaskSource*, base::TaskTraits const&) [task_tracker.cc : 783 + 0x8]
fp = 0x0000000176db6cc0 lr = 0x0000000103edf000
sp = 0x0000000176db6c10 pc = 0x0000000103ebdf74
Found by: previous frame's frame pointer
11 Electron Framework!base::internal::TaskTrackerPosix::RunTask(base::internal::Task, base::internal::TaskSource*, base::TaskTraits const&) [task_tracker_posix.cc : 22 + 0x10]
fp = 0x0000000176db6e90 lr = 0x0000000103ebdb84
sp = 0x0000000176db6cd0 pc = 0x0000000103edf000
Found by: previous frame's frame pointer
12 Electron Framework!base::internal::TaskTracker::RunAndPopNextTask(base::internal::RegisteredTaskSource) [task_tracker.cc : 505 + 0x14]
fp = 0x0000000176db6f70 lr = 0x0000000103ec46ec
sp = 0x0000000176db6ea0 pc = 0x0000000103ebdb84
Found by: previous frame's frame pointer
13 Electron Framework!base::internal::WorkerThread::RunWorker() [worker_thread.cc : 349 + 0xc]
fp = 0x0000000176db6f90 lr = 0x0000000103ec4508
sp = 0x0000000176db6f80 pc = 0x0000000103ec46ec
Found by: previous frame's frame pointer
14 Electron Framework!base::internal::WorkerThread::RunPooledWorker() [worker_thread.cc : 223 + 0x0]
fp = 0x0000000176db6fc0 lr = 0x0000000103edf450
sp = 0x0000000176db6fa0 pc = 0x0000000103ec4508
Found by: previous frame's frame pointer
15 Electron Framework!base::(anonymous namespace)::ThreadFunc(void*) [platform_thread_posix.cc : 87 + 0xc]
fp = 0x0000000176db6fe0 lr = 0x000000018418d06c
sp = 0x0000000176db6fd0 pc = 0x0000000103edf450
Found by: previous frame's frame pointer
16 libsystem_pthread.dylib + 0x7068
fp = 0x0000000000000000 lr = 0xec08800184187da0
sp = 0x0000000176db6ff0 pc = 0x000000018418d06c
Found by: previous frame's frame pointer
Above crash is most likely fixed by https://chromium-review.googlesource.com/c/v8/v8/+/2378307 , need to confirm.
Wasm modules doesn't load with cross-compiled mac arm64 version, reported upstream at https://bugs.chromium.org/p/chromium/issues/detail?id=1150060
This issue on Node, nodejs/node#36160, points to this merged PR as a potential fix for wasm module loading failure nodejs/node#35986. The PR cherry-picks some changes from v8 upstream. The changes from the PR have not landed in a Node release yet, however, as of v15.2.1.
Thanks for looking into it, the electron version we ship for the exploration build also carries those patches. The problem is that those changes are behind V8_HOST_ARCH_ARM64 macro and the electron releases are currently cross-compiled, hence I have opened the chromium issue to investigate fix for cross-compiled builds.
Upstream issue clarified about the usage of V8_HOST_ARCH_ARM64 macro, waiting on a new electron release 11.0.3 to test electron/electron#26650
@deepak1556 Electron has released v11.0.3. https://www.electronjs.org/releases/stable#11.0.3
Although it's not in the release notes, it contains the commit that rolls back the darwin-arm64 patches that were deemed unnecessary by upstream Chromium. Should be testable in a build of VSCode now.
slightly off topic: cpptools and live-share do not appear to work:
- cpptools:
Architecture arm64 is not supported(it seems it does support arm64 in some way now but maybe this is just not recognising the platform completely correctly) - live-share after login with github redirect:
Unsupported redirection domain.(vscodium seems to have the same issues so it may be something about this new build not being "official" enough yet I guess)
I think the teams might already be working on those so I'll just note it here instead of opening issues everywhere for now
https://www.zdnet.com/article/microsoft-we-want-to-bring-vs-code-to-apples-mac-on-arm-silicon/
We've identified the most popular extensions with native dependencies and we're working with their maintainers to ensure that they are updated to run on ARM too, for all operating systems.
Our ci was having some trouble for the past 2 days, so builds have been delayed. But good news, latest release based on 11.0.3 fixes the loading of wasm module.
The final bit left to promote the exploration build to insiders is depending on availability of internal electron arm64 builds.
@exiadbq the issue is fixed with latest builds with commit a31f124319, please update. Thanks!
The final bit left to promote the exploration build to insiders is depending on availability of internal electron arm64 builds.
@deepak1556 Is there any tracking issue to track the progress on Microsoft-internal Electron arm64 builds?
There is no separate public issue, all updates will be posted here.
As November is over, is there an updated estimate as to when the stable arm64 build will be available?
(don't mean to be rude, just deciding on getting a new machine)
Our focus right now is on delivering an Insiders build. Getting a Stable build will be the next step depending on how the experience goes.
For what it’s worth, I’ve been using the Exploration build for the last 10 days and it’s now fairly stable. Most of my issues developing on a M1 Mac are due to other tools rather than VS Code :) (Docker, gpg-agent, Go, etc)
On the exploration build I'm not able to activate pylance. I'm getting this error
workbench.desktop.main.js:5431 Activating extension 'ms-python.vscode-pylance' failed: You may install and use any number of copies of the software only with Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server, and successor ................
Is that just due to it being an exploration build?
I can say that during last 2 weeks I didn't have problems with exploration build on apple silicon. Good work! Happy to see stable version soon.
Good to see that! Some people on reddit were telling me that it was very buggy, but that was back in November. Looks like most of the bugs have been ironed out.
Only issue with exploration build is tailwind intellisense plugin not working properly. Works on latest insiders. Unsure if it's vscode or the plugin
How far is VS Code away from having an Insider build which works natively on Apple Silicon? Any ETA for when the team thinks they'll have what it needs to run on an M1?
How far is VS Code away from having an Insider build which works natively on Apple Silicon? Any ETA for when the team thinks they'll have what it needs to run on an M1?
@deepak1556 mentioned in here microsoft/vscode-remote-release#4069 (comment) that it will be the next Insider build after stable 1.52 so I guess we will see it very soon, maybe next week.
Insider works as native.
On Sat, 12 Dec 2020 at 11:04 Dustin Moris Gorski @.***> wrote: How far is VS Code away from having an Insider build which works natively on Apple Silicon? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#106770 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAISLXI6RVN2OBFFSKKPYMLSUM54TANCNFSM4RNH6Z4A .
-- [image: created with MySignature.io] https://mysignature.io/?utm_source=logo Erich Stark Owner & UI Developer | Stark Codes mobile: +421904616608 site: starkcodes.com email: erich@stark.codes
The latest insider build
Version: 1.53.0-insider
Commit: 76436a4
Date: 2020-12-11T17:46:02.603Z (18 hrs ago)
still runs via Rosetta 2. Only Exploration build runs natively.
@lxyzzhao of course, my mistake. I use Exploration build.
According to #111406, automatic insider builds from master have been re-enabled after releasing v1.52. Doesn't that mean we should see an Insiders build with Apple Silicon support? Is it just that the links on the website haven't been updated, or Insiders hasn't actually been built with Electron 11.0.3/Apple Silicon patches yet?
Apple Silicon Support isn't available with an Insiders build, but it will be included in the next Insiders build as described a few comments above (#106770 (comment))
Sorry for the confusion here, the insiders build with native arm support has been out from (12/11/20), the links in the website still point to exploration build. I will update them today.
Here is the download link to get started on this flavor: https://az764295.vo.msecnd.net/insider/96b426ef1da0f0a51ce9ef1931cd1fd2322547e4/VSCode-darwin-arm64.zip
Oh wow, so you're saying that the download in red has had native arm64 support since mid November?
@dustinmoris No, that download link still points to an x64 build of Insiders. And no, it hasn't been available since mid-November, because @deepak1556 is using US date format (MM/DD/YY), so the insiders build for ARM has been available for just 3 days
@deepak1556 Will the exploration build be deprecated after the Insiders build is published? Any reason we might want to keep both of them installed on our system?
No, the exploration builds will continue to exist. The exploration builds have always been available on a nightly basis we just don't advertise it. This particular case for mac arm builds is unique because the arm binaries from Electron are tied to some versions and we weren't ready to push them to insiders.
The purpose of the exploration build flavour is to get builds with newer electron runtimes as early as possible for testing. So we will be keep updating the exploration builds.
Insiders is always comparatively stable to exploration, so its upto the user to choose which flavor they want to stay on depending on their use case.
Once it's ready, will the user be able upgrade to a stable ARM build from x86 build with Code's build in "Check for updates..." option? Or should the user manually upgrade it? (e.g. uninstall x86 version then install ARM build.)
Once it's ready, will the user be able upgrade to a stable ARM build from x86 build with Code's build in "Check for updates..." option? Or should the user manually upgrade it? (e.g. uninstall x86 version then install ARM build.)
(Not an official answer) As I understand it, Electron apps cannot currently be built as universal binaries. Instead, you tend to see builds for each (e.g., these VSCode builds; Slack). Eventually, Electron will have the ability to do universal binaries, though they say that they'll be "huge."
My guess is that they'll do something similar to Slack: updates from x86 will stay x86 (see e.g., the MAS build of Slack 4.11.3 is x86, despite an Apple Silicon build of that version being available directly), even after standalone Apple Silicon builds are available. Once universal binaries are available, an update from x86 will likely be a universal binary.
+1 on interest in an official answer, though.
Once it's ready, will the user be able upgrade to a stable ARM build from x86 build with Code's build in "Check for updates..." option? Or should the user manually upgrade it? (e.g. uninstall x86 version then install ARM build.)
(Not an official answer) As I understand it, Electron apps cannot currently be built as universal binaries. Instead, you tend to see builds for each (e.g., these VSCode builds; Slack). Eventually, Electron will have the ability to do universal binaries, though they say that they'll be "huge."
My guess is that they'll do something similar to Slack: updates from x86 will stay x86 (see e.g., the MAS build of Slack 4.11.3 is x86, despite an Apple Silicon build of that version being available directly), even after standalone Apple Silicon builds are available. Once universal binaries are available, an update from x86 will likely be a universal binary.
+1 on interest in an official answer, though.
I honestly prefer having a separate build for each - universal binaries tend to be much larger and take up more space on disk. If all my apps were universal binaries, they would quickly add up, and it's not that much work to select the currect build to download off of a website, especially for a developer-focused tool like VSCode. Even Chrome, a consumer-focused tool, still offers two builds on their website: "Macs with Intel chip" and "Macs with Apple chip" - which I think is friendly enough. Although, their build for "Macs with Apple chip" is a universal binary. The Slack website is not a bad example, either.
In my opinion, universal binaries are really just a "temporary" solution for Apple to retain their magical "it just works" during this transition. Obviously, the transition will take a while to complete even after the last Intel Macs in their lineup are updated.
I've been using both Exploration and Insiders and have been seeing frequent crashes of the Extension Host with SIGILL. Opened #113410
I can't seem to get the arm64 version to run at all. It just crashes right away.
OS X = 11.1
VSCode-darwin-arm64.zip
@stevesuh I experienced the same thing but the link in this comment worked for me: #106770 (comment)
Same as the above 2 comments, and the link @aclysma pointed to works. Except that it will prompt to update to the newer version, which is apparently broken (at least for me and the other 2 people), so just a heads up: DO NOT update to latest version, yet.
I updated through the app a while back (insiders version) and it works as expected. I haven't found anything broken through my normal day-to-day usage. Is there something I should look out for?
proof I'm on the latest version
app info:
Weird that I couldn't even open the app with the latest version downloaded from https://code.visualstudio.com/insiders/
So I tried the old version posted above, and it worked. Then I saw the notification to update the app. To no surprises, it no longer works.
I read @ngocphamm's comment right after I updated (exploration build).
Is there a value in me spending some time testing the updated exploration build?
Also, in case it doesn't work, what is the cleanest way to undo the update?
- are you guys using the exploration build or the insiders build?
- could you guys check what version of either build your on (app info)
Ive heard that the insiders build is drastically more stable than the exploration build, I would use that one
I'm using Insiders build (the link I provdied 2 comments above). App info looks exactly like yours, so I'm not sure why it doesn't work on my mac, and does on yours @shaunsingh
I'm using exploration build (screenshot below after I took the update):
I'm using Insiders build (the link I provdied 2 comments above). App info looks exactly like yours, so I'm not sure why it doesn't work on my mac, and does on yours
I am also running the latest Insiders build on my M1 MBP with no issues.
So it looks like it's my issue in particular, and not a wide spread one. Sorry for saying like it is.
I also checked the checksum for the download from https://code.visualstudio.com/insiders/, so I'm not sure what's wrong here. No crash report from Console.app, either.
Since version numbers don't change for Insiders builds within the month, It's more useful to provide the commit hash. I am on the Insiders build and I also have "No updates available," like @shaunsingh, and it works just fine on my machine.
Here's my version information:
Version: 1.53.0-insider
Commit: 4a875e23d20b64504a818834f3fa4c40adb8d480
Date: 2020-12-21T12:34:09.548Z
Electron: 11.1.0
Chrome: 87.0.4280.88
Node.js: 12.18.3
V8: 8.7.220.29-electron.0
OS: Darwin arm64 20.2.0
How can I get such info if I can't open the app @richiksc ?
EDIT: This is the version that's working fine here. As soon as I choose to update it to the latest version (not sure what commit is that), it crashes every single time during start up.
Version: 1.53.0-insider
Commit: 96b426ef1da0f0a51ce9ef1931cd1fd2322547e4
Date: 2020-12-14T05:49:14.788Z
Electron: 11.0.3
Chrome: 87.0.4280.67
Node.js: 12.18.3
V8: 8.7.220.25-electron.0
OS: Darwin arm64 20.2.0
How can I get such info if I can't open the app @richiksc ?
Hmm, I found out that if you go to Applications in Finder, find Visual Studio Code Insiders, right click and select "Show Package Contents", then you can navigate to Contents/Resources/app/product.json, and if you scroll down on that file there will be a field for "commit" with the commit hash.
Another thing you can try is installing the code-insiders command on the version that works (Command Palette > "Shell Command"), then updating, and then trying to open vscode from the command line with --disable-extensions, to see if it might be an issue with an extension you have.
% code-insiders --disable-extensions
Thanks @richiksc. This is for the version that crashes. It looks like it's the same with yours.
"commit": "4a875e23d20b64504a818834f3fa4c40adb8d480",
"date": "2020-12-21T12:34:09.548Z",
I'm quite sure it's not extensions, as this happens with me having no extensions installed at all. I downloaded the package from the website https://code.visualstudio.com/insiders/, and it crashes right out of the box. Didn't even have a chance to install extensions 😅
checking that product.json file, I found the following information
"commit": "4a875e23d20b64504a818834f3fa4c40adb8d480"
As you can see, its the same version as @richiksc, everything working fine
I'm clueless, so I will just wait until there's a new build of Insiders and try it out. It works okay with me now with the older version, and set to no auto update 😄
Thanks @richiksc. This is for the version that crashes. It looks like it's the same with yours.
"commit": "4a875e23d20b64504a818834f3fa4c40adb8d480", "date": "2020-12-21T12:34:09.548Z",I'm quite sure it's not extensions, as this happens with me having no extensions installed at all. I downloaded the package from the website https://code.visualstudio.com/insiders/, and it crashes right out of the box. Didn't even have a chance to install extensions 😅
Hmm... I'm quite lost then. It is probably an issue with your system configuration in particular. What version of macOS are you using? I am using Big Sur 11.1 (20C69) [Accessible from About This Mac > Hover over version number for a while]. I think you'll need someone from the VSCode team to debug. @deepak1556, are there any known issues with the latest Insiders build 4a875e2 on Apple Silicon?
Same OS version here. I haven't tried restarting my mac, but I don't really want to do that at the time 😅
I have another friend with a M1 mac, and he does not have any issue opening the app downloaded from the insider page. It's just me... Thanks for chiming in guys! Much appreciated! I will just wait for a new build.
I was having the same problem as @ngocphamm which seems to be from having an Intel insiders build and then switching to a ARM one. After removing all of the cache and pref files for insiders, it started up correctly. When it did fail to start, it dis leave this in the system.log:
Dec 29 11:10:05 tentacle com.apple.xpc.launchd[1]: Coalition Cache Hit: app<application.com.microsoft.VSCodeInsiders.1171406.1171412(501)> [952]
Dec 29 11:10:05 tentacle Code - Insiders Helper (GPU)[1036]: getattrlist failed for /System/Library/Frameworks/OpenGL.framework/Resources//GLRendererFloat.bundle/GLRendererFloat: #2: No such file or directory
Dec 29 11:10:05 tentacle VTDecoderXPCService[1037]: DEPRECATED USE in libdispatch client: Changing the target of a source after it has been activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 11:10:05 tentacle VTDecoderXPCService[1037]: DEPRECATED USE in libdispatch client: Changing target queue hierarchy after xpc connection was activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 11:10:05 tentacle VTDecoderXPCService[1037]: DEPRECATED USE in libdispatch client: Changing the target of a source after it has been activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 11:10:05 tentacle VTDecoderXPCService[1037]: DEPRECATED USE in libdispatch client: Changing target queue hierarchy after xpc connection was activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 11:10:05 tentacle com.apple.xpc.launchd[1] (application.com.microsoft.VSCodeInsiders.1171406.1171412[1025]): Service exited due to SIGBUS | sent by exc handler[1025]
Dec 29 11:10:05 tentacle VTDecoderXPCService[1037]: DEPRECATED USE in libdispatch client: Changing the target of a source after it has been activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 11:10:05 tentacle VTDecoderXPCService[1037]: DEPRECATED USE in libdispatch client: Changing target queue hierarchy after xpc connection was activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 11:10:05 tentacle VTDecoderXPCService[1037]: DEPRECATED USE in libdispatch client: Changing the target of a source after it has been activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 11:10:05 tentacle VTDecoderXPCService[1037]: DEPRECATED USE in libdispatch client: Changing target queue hierarchy after xpc connection was activated; set a breakpoint on _dispatch_bug_deprecated to debug
I was perhaps a bit heavy handed in removing prefs so unsure which was the culprit:
- ~/Library/Application Support/Code - Insiders
- ~/Library/Caches/com.microsoft.VSCodeInsiders
- ~/Library/Saved Application State/com.microsoft.VSCodeInsiders.savedState
- ~/Library/Preferences/com.microsoft.VSCodeInsiders.plist
- ~/Library/Caches/com.microsoft.VSCodeInsiders.ShipIt
I think the issue was probably that they accidentally downloaded the intel version, or something went wrong on the site, nice that's its resolved now
Yep this is the issue. Thanks @nathanhruby. I don't even remember I downloaded and ran the Intel version first.
@deepak1556 Is it possible to check the previous preferences directories on a new install of the ARM version and either purge them or warn the user to delete them if they contain any Intel-specific info? Is there even any way to tell if the Library files were created from an Intel or an ARM version of VSCode?
I'm still not quite following. This older link works: https://az764295.vo.msecnd.net/insider/96b426ef1da0f0a51ce9ef1931cd1fd2322547e4/VSCode-darwin-arm64.zip
Upgrading it causes it to crash.
Removing all the directories @nathanhruby recommends even though I just had the stable Intel version installed and installing from this link: https://code.visualstudio.com/insiders/
causes it to crash.
I did have the Intel version(stable version not insider) but I moved into Trash can as well.
From product.json
"commit": "4a875e23d20b64504a818834f3fa4c40adb8d480",
"date": "2020-12-21T12:34:09.548Z",
From system.log:
Dec 29 20:13:20 Steves-Mac-mini com.apple.xpc.launchd[1]: Coalition Cache Hit: app<application.com.microsoft.VSCodeInsiders.1436377.1436383(501)> [11202]
Dec 29 20:13:21 Steves-Mac-mini Code - Insiders Helper (GPU)[30155]: getattrlist failed for /System/Library/Frameworks/OpenGL.framework/Resources//GLRendererFloat.bundle/GLRendererFloat: #2: No such file or directory
Dec 29 20:13:21 Steves-Mac-mini VTDecoderXPCService[30156]: DEPRECATED USE in libdispatch client: Changing the target of a source after it has been activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 20:13:21 Steves-Mac-mini VTDecoderXPCService[30156]: DEPRECATED USE in libdispatch client: Changing target queue hierarchy after xpc connection was activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 20:13:21 Steves-Mac-mini VTDecoderXPCService[30156]: DEPRECATED USE in libdispatch client: Changing the target of a source after it has been activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 20:13:21 Steves-Mac-mini VTDecoderXPCService[30156]: DEPRECATED USE in libdispatch client: Changing target queue hierarchy after xpc connection was activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 20:13:21 Steves-Mac-mini VTDecoderXPCService[30156]: DEPRECATED USE in libdispatch client: Changing the target of a source after it has been activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 20:13:21 Steves-Mac-mini VTDecoderXPCService[30156]: DEPRECATED USE in libdispatch client: Changing target queue hierarchy after xpc connection was activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 20:13:21 Steves-Mac-mini VTDecoderXPCService[30156]: DEPRECATED USE in libdispatch client: Changing the target of a source after it has been activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 20:13:21 Steves-Mac-mini VTDecoderXPCService[30156]: DEPRECATED USE in libdispatch client: Changing target queue hierarchy after xpc connection was activated; set a breakpoint on _dispatch_bug_deprecated to debug
Dec 29 20:13:21 Steves-Mac-mini com.apple.xpc.launchd[1] (application.com.microsoft.VSCodeInsiders.1436377.1436383[30152]): Service exited due to SIGBUS | sent by exc handler[30152]
Version: 1.53.0-insider
Commit: 96b426ef1da0f0a51ce9ef1931cd1fd2322547e4
Date: 2020-12-14T05:49:14.788Z
Electron: 11.0.3
Chrome: 87.0.4280.67
Node.js: 12.18.3
V8: 8.7.220.25-electron.0
OS: Darwin arm64 20.2.0
That older version is what is working. I cannot get the new version to work even after
- Removing all the ~/Library directories
- Making sure no version of Visual Studio Code is installed.
- Trying to install the latest version of Insider.
I just repeated the steps to make sure it was as clean an install as possible.
Dec 29 20:37:35 Steves-Mac-mini Code - Insiders Helper (GPU)[1797]: getattrlist failed for /System/Library/Frameworks/OpenGL.framework/Resources//GLRendererFloat.bundle/GLRendererFloat: #2: No such file or directory
Hopefully that can help to troubleshoot.
When you move something to the trash, it only moves the binaries, all the user data and other stuff will still be in the system
looks like you left some residual from the intel one so it didn’t reinstall the files, and may have deleted some opengl file hat vscode is missing.
There are some tools (like cleanmymacx) that allows you to delete all the files from the app, maybe try something like that?
@shaunsingh if this is true then how come the older commit is working from 12/14? Also one was a different package since it's stable version and the other one was Insider version. Anyway I still think this is a bug. The user should not have to know about path collisions. One is Intel stable version and the other is M1 Insider edition.
I recommend the free AppCleaner: brew install appcleaner
In that case, it shouldn’t be an issue because iirc stable and insider versions can coexist, are you sure you didn’t install the intel insiders version?
Ah you are right. I must have installed it first and forgot. 🤦
I went ahead and reinstalled the x86 Insiders Edition used AppCleaner and reinstalled M1 Insiders Edition and it works now. I did rm -rf on the directories so I figured that was nuclear enough but something was still persisting. Thanks for your help @shaunsingh and @justinko
I too had to use appcleaner to be able to use the arm64 insiders build today
Sorry about the startup crash, it arises from that fact v8 cache data written by intel app is not readable by the arm version. You can start the app with --no-cached-data instead of having to delete the data folders to workaround. Will implement a fix this iteration.
Apple silicon builds will be pushed to stable with upcoming 1.53 release, thanks all for the help with identifying issues early on. The current plan is to have the default download as a universal while we will still continue to provide architecture specific downloads #114974.
As end user you shouldn't observe any changes when installing the universal stable build app on your apple silicon device, everything should just work even if you had previously been running the intel version.
We won't push universal app as an update to your existing x86_64 app on intel device or arm64 app on apple silicon device. They will continue to receive their architecture specific updates, we don't have timeline yet for when we will completely unify them.
@deepak1556 Is there an anticipated timeline for when 1.53 will be out or somewhere I can track progress towards that?
Unfortunately I believe an arm64 build will result in a lot of trouble for users because Apple recently broke nodejs in macOS 11.2 which is also very close to being released.
macOS 11.2 is RC3 and will land any day now.
This problem also occurs in VSCode Insiders on macOS 11.2 betas as per #113410 (comment)
Since my last comment 3 hours ago, Apple released macOS 11.2, with the same build number as RC3.
Apple silicon stable release will be delayed for another iteration to accommodate the fix for #115646, sorry all!
hi, I downloaded 1.53 stable and it is intel x64 not arm64. so back to insiders edition for me. please can you update the website, as 1.53 is not arm64 just yet.
as the previous comment before yours said, arm64 builds have been delayed to the next release. I don't see a mention of arm64 on the stable download site.