vscode-extensions.vadimcn.vscode-lldb: Error failed to get reply to handshake packet on x86_64-darwin
#148946
Assignees
Labels
0.kind: bug
Something is broken
6.topic: darwin
Running or building packages on Darwin
6.topic: vscode
Comments
|
Sorry, i no longer use vscode. |
|
@oxalica Fair enough, I'll pick away at this in my spare moments and if I sort this out I'll raise a pull request. |
|
this issue is still present. |
|
I feel like the build itself is broken. I wonder if it will help if we can bring the build closer two what we get via @nigelgbanks, have you actually had a time to look into this problem? |
|
I've unfortunately not had time to dig into this further. |
13 tasks
qrlex
pushed a commit
to qrlex/nixpkgs
that referenced
this issue
Oct 9, 2023
Summary:
vscode-lldb has been broken on Darwin due to a build-time issue:
* on Darwin, the vscode-lldb build scripts expect $HOME to exist and be
writable, NixOS#202507
and several runtime-issues:
* codelldb can't find its dynamic libraries (NixOS#160874)
* lldb-server from nixpkgs doesn't work due to missing the
"com.apple.security.cs.debugger"
macOS codesigning entitlement, (NixOS#38624), also with the symptom that
tccd, the macOS "Transparency, Consent, and Control" daemon, denies
requests it receives from vscode/codium with log messages like:
"AUTHREQ_CTX: msgID=..., function=<private>, service=kTCCServiceDeveloperTool, preflight=yes, query=1,"
"Service kTCCServiceDeveloperTool does not allow prompting; returning denied."
"AUTHREQ_RESULT: msgID=..., authValue=0, authReason=5, authVersion=1, error=(null),", etc.
* lldb-server from nixpkgs may also provide a different CLI interface than
codelldb expects on macOS.
* vscode-lldb directs lldb to load rust pretty-printing scripts which need
to be preserved through the build process in nixpkgs
Solution:
* The build problem can be fixed by setting HOME="$(pwd)/home", as suggested
in NixOS#202507.
* The dynamic libraries issue can be fixed by setting LD_LIBRARY_PATH while
wrapping codelldb
* The permissions issue and CLI interface issue can both be fixed by using
Xcode's debugserver,
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver
on macOS, since it has the required entitlement and the expected interface.
* Finally, the script-loading issue can be fixed by copying the required
scripts to the location that vscode-lldb expects to find them in.
Fixes:
* NixOS#148946: Error failed to get reply to handshake packet on x86_64-darwin
with vscode-extensions.vadimcn.vscode-lldb
* NixOS#160874: codelldb inside of vscode-lldb extension doesn't work
* NixOS#202507: vscode-extensions.vadimcn.vscode-lldb fails to build on aarch64-darwin
(cherry picked from commit fa70e7499b08524a4a02e7ce9e39847b9d3c95df)
wegank
pushed a commit
to mstone/nixpkgs
that referenced
this issue
Apr 10, 2024
Summary:
vscode-lldb has been broken on Darwin due to a build-time issue:
* on Darwin, the vscode-lldb build scripts expect $HOME to exist and be
writable, NixOS#202507
and several runtime-issues:
* codelldb can't find its dynamic libraries (NixOS#160874)
* lldb-server from nixpkgs doesn't work due to missing the
"com.apple.security.cs.debugger"
macOS codesigning entitlement, (NixOS#38624), also with the symptom that
tccd, the macOS "Transparency, Consent, and Control" daemon, denies
requests it receives from vscode/codium with log messages like:
"AUTHREQ_CTX: msgID=..., function=<private>, service=kTCCServiceDeveloperTool, preflight=yes, query=1,"
"Service kTCCServiceDeveloperTool does not allow prompting; returning denied."
"AUTHREQ_RESULT: msgID=..., authValue=0, authReason=5, authVersion=1, error=(null),", etc.
* lldb-server from nixpkgs may also provide a different CLI interface than
codelldb expects on macOS.
* vscode-lldb directs lldb to load rust pretty-printing scripts which need
to be preserved through the build process in nixpkgs
Solution:
* The build problem can be fixed by setting HOME="$(pwd)/home", as suggested
in NixOS#202507.
* The dynamic libraries issue can be fixed by setting LD_LIBRARY_PATH while
wrapping codelldb
* The permissions issue and CLI interface issue can both be fixed by using
Xcode's debugserver,
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver
on macOS, since it has the required entitlement and the expected interface.
* Finally, the script-loading issue can be fixed by copying the required
scripts to the location that vscode-lldb expects to find them in.
Fixes:
* NixOS#148946: Error failed to get reply to handshake packet on x86_64-darwin
with vscode-extensions.vadimcn.vscode-lldb
* NixOS#160874: codelldb inside of vscode-lldb extension doesn't work
* NixOS#202507: vscode-extensions.vadimcn.vscode-lldb fails to build on aarch64-darwin
superherointj
changed the title
failed to get reply to handshake packet on x86_64-darwin with vscode-extensions.vadimcn.vscode-lldbfailed to get reply to handshake packet on x86_64-darwin
|
Seems fixed by #211321 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
On
x86_64-darwinthe VS Code pluginvscode-extensions.vadimcn.vscode-lldbfails to connect to the debugger after starting. With the messagefailed to get reply to handshake packet.If I install VSCode and the plugin manually it works as expected. That being said others not using
nixpkgshave encountered this issue as well. I've put some effort into debugging the issue though not much luck.Steps To Reproduce
I've attached a minimal reproducible example project that uses flakes.
Issue.zip
x86_64-darwinmachine./Applicationsfolder.rm -fr $HOME/Library/Application\ Support/Code/rm -rf $HOME/.vscodenix develop.code .to open visual studio code.src/main.rcExpected behavior
The debugger attaches to the process and stops on the set breakpoint.
Screenshots
The following is the log output of
codelldb.Additional context
Attempts to resolve the issues and others who are experiencing it in different context is here.
Notify maintainers
@oxalica
Metadata
Maintainer information:
The text was updated successfully, but these errors were encountered: