Cannot launch executable: Sending vRun packet failed

[bratinba]

When trying to debug my C++ code in vscode with the CodeLLDB extension, I get the following error:

Cannot launch 'path_to_executable': Sending vRun packet failed.

Other debugger work fine.

The extension version is 1.11.1
I am running the code in an Ubuntu 22.04 aarch64 based dev container with glibc 2.35
My device runs macOS.

My launch.json

{
    "name": "(lldb) debug main",
    "type": "lldb",
    "request": "launch",
    "program": "${workspaceFolder}/core/build/main_executable",
    "args": []
}

[asl]

What is your lldb version? Can you reproduce the problem with plain lldb? If not, then I'd suggest you to submit issue to CodeLLDB: https://github.com/vadimcn/codelldb

[llvmbot]

@llvm/issue-subscribers-lldb

Author: None (bratinba)

When trying to debug my C++ code in vscode with the CodeLLDB extension, I get the following error:

Cannot launch 'path_to_executable': Sending vRun packet failed.

Other debugger work fine.

The extension version is 1.11.1
I am running the code in an Ubuntu 22.04 aarch64 based dev container with glibc 2.35
My device runs macOS.

My launch.json

{
    "name": "(lldb) debug main",
    "type": "lldb",
    "request": "launch",
    "program": "${workspaceFolder}/core/build/main_executable",
    "args": []
}

[bratinba]

lldb works, therefore wrong place for the ticket

[gstelmack]

From my own testing, lldb 17 (which shipped with codelldb 1.10.0) works fine. The current lldb-dap extension, codelldb 1.11.+ (which ships with lldb 19) and lldb 18.1.8 from the command line all fail for me with a vscode dev container using docker (Rancher Desktop in my case, unsure of other reports) on an Apple Silicon Mac (M4 MacBook here) and MacOS Sequoia.

[kiwi142857]

I face the same problem. I ran a docker with ubuntu:22.04 on my MacBook M4.
here is my launch.json

{
  "configurations": [
    {
      "name": "C/C++: run rdt_sim (GDB)",
      "type": "lldb",
      "request": "launch",
      "program": "${workspaceFolder}/Lab1/rdt/rdt_sim",
      "args": [
        "1000",
        "0.1",
        "100",
        "0",
        "0",
        "0",
        "0"
      ],
      "cwd": "${workspaceFolder}/Lab1/rdt",
      "preLaunchTask": "build-rdt-sim"
    }
  ]
}

[laverdet]

I've been experiencing this this issue since upgrading to the M4 architecture in 2024. I was hoping it would be fixed in due time but it doesn't appear to be the case.

For posterity, another person raised this on the mailing list with no response:
https://www.mail-archive.com/llvm-bugs@lists.llvm.org/msg84221.html

I took some time to dive in and narrow it down. The first insight missing in other reports is that this wasn't an issue on the M1 architecture, which is what I was using before November. I can't confirm since I traded in the computer so I may be mistaken.

System Information

I disabled SIP (System Integrity Protection) which tends to cause problems with this kind of thing. I verified plain as day that it is an issue on a clean install of macOS:

marcel [~] sw_vers
ProductName:		macOS
ProductVersion:		15.4
BuildVersion:		24E248

marcel [~] uname -a
Darwin marcel.local 24.4.0 Darwin Kernel Version 24.4.0: Wed Mar 19 21:17:35 PDT 2025; root:xnu-11417.101.15~1/RELEASE_ARM64_T6041 arm64

marcel [~] csrutil status
System Integrity Protection status: disabled.

marcel [~] docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined -it debian:experimental

root@6c4d4d719637:/# cat /proc/cpuinfo  | head -n9
processor	: 0
BogoMIPS	: 48.00
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 flagm2 frint svei8mm svebf16 bf16 afp sme
CPU implementer	: 0x61
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0x000
CPU revision	: 0

root@6c4d4d719637:/# apt-get update && apt-get install -y lldb-20
# Omitted

root@6c4d4d719637:/# lldb-20 cat
(lldb) target create "cat"
Current executable set to '/usr/bin/cat' (aarch64).
(lldb) run
error: Cannot launch '/usr/bin/cat': Sending vRun packet failed
(lldb) quit

root@6c4d4d719637:/# apt-get update && apt-get install -y lldb-17
# Omitted

root@6c4d4d719637:/# lldb-17 cat
(lldb) target create "cat"
Current executable set to '/usr/bin/cat' (aarch64).
(lldb) run
Process 3443 launched: '/usr/bin/cat' (aarch64)
Process 3443 exited with status = 0 (0x00000000)

Bisect

I went through a bisect to narrow it down. The process was straightforward enough.

git bisect start
# status: waiting for both good and bad commits
# bad: [461274b81d8641eab64d494accddc81d7db8a09e] MIPS: Fix asm constraints "f" and "r" for softfloat (#79116)
git bisect bad 461274b81d8641eab64d494accddc81d7db8a09e
# status: waiting for good commit(s), bad commit known
# good: [6009708b4367171ccdbf4b5905cb6a803753fe18] Revert "[runtimes] Add missing test dependencies to check-all (#72955)"
git bisect good 6009708b4367171ccdbf4b5905cb6a803753fe18
# good: [d0b54bb50e5110a004b41fc06dadf3fee70834b7] [Clang] use unsigned integer constants in unit-test | fixes build error on ppc64le-lld-multistage-test
git bisect good d0b54bb50e5110a004b41fc06dadf3fee70834b7
# bad: [8511ade505588473154906e903302659fd833b48] [LegacyPM] Remove LowerExpectIntrinsicPass
git bisect bad 8511ade505588473154906e903302659fd833b48
# good: [11ce3d99b7654a2211ce6ab56eb9d0667efe0939] [llvm] Add LLVM_CTOR_NODISCARD (#65418)
git bisect good 11ce3d99b7654a2211ce6ab56eb9d0667efe0939
# bad: [6716d3dd77fcf9b6bb897adffb08b147f30a11c8] Move test split-deadloop.mir that was added in e3d714f to AArch64 directory instead of ARM.
git bisect bad 6716d3dd77fcf9b6bb897adffb08b147f30a11c8
# good: [177f9ab2fbd868fb9cc7d5504e56a241e8e79329] [clang][Interp] Check pointer inc/dec ops for initialization
git bisect good 177f9ab2fbd868fb9cc7d5504e56a241e8e79329
# bad: [3c61e4bf28538f5f267b073634e394dd5000af85] Copy and paste error in a file header.
git bisect bad 3c61e4bf28538f5f267b073634e394dd5000af85
# good: [13deda4f223ba7d0d26b6448080528e1c0f4bab1] [NFC][hwasan] Remove default argument
git bisect good 13deda4f223ba7d0d26b6448080528e1c0f4bab1
# bad: [97abf2e75597abf7324ae31b8ca80dae5f89846f] [NFC][hwasan] Find overflow candidate early (#66682)
git bisect bad 97abf2e75597abf7324ae31b8ca80dae5f89846f
# bad: [9b5ef2bea8e3de8fd564ab74b8123b446883216f] [mlir][Interfaces] `LoopLikeOpInterface`: Support ops with multiple regions (#66754)
git bisect bad 9b5ef2bea8e3de8fd564ab74b8123b446883216f
# good: [c8090512157ab0aad1e43e398598e689b7e55a52] [NFC] Preparatory work for D153131 (#66750)
git bisect good c8090512157ab0aad1e43e398598e689b7e55a52
# bad: [9120e854486d00307e14751769200ae4c45909a9] [Dexter] Associate parser errors with correct file (#66765)
git bisect bad 9120e854486d00307e14751769200ae4c45909a9
# bad: [a2a1dbb518ab836ca644275867b33b24bb7df8ab] [mlir] avoid crash in transform.sequence verifier (#66756)
git bisect bad a2a1dbb518ab836ca644275867b33b24bb7df8ab
# good: [1d305f95d60e04790f08b10261fff537311c191d] [AMDGPU] Fix line endings in a test
git bisect good 1d305f95d60e04790f08b10261fff537311c191d
# bad: [d99d9d8b74ffcb8ac418fcdafa750b07f2bd9935] [lldb][AArch64] Add SME's Array Storage (ZA) register
git bisect bad d99d9d8b74ffcb8ac418fcdafa750b07f2bd9935
# good: [e0919b189bf2df4f97f22ba40260ab5153988b14] [CodeGen] Renumber slot indexes before register allocation (#66334)
git bisect good e0919b189bf2df4f97f22ba40260ab5153988b14
# first bad commit: [d99d9d8b74ffcb8ac418fcdafa750b07f2bd9935] [lldb][AArch64] Add SME's Array Storage (ZA) register

Diving in

The first bad commit [d99d9d8] adds support for SME's ZA register. This was followed up with a0768b8 & 46b961f. Later, b8150c8 adds support for SME2.

What I'm seeing on my machine is ptrace PTRACE_GETREGSET w/ NT_ARM_SVE does not return success. Therefore the following code does not run:

llvm-project/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp

Lines 278 to 279 in 5c45e23

	if (m_opt_regsets.AnySet(eRegsetMaskSSVE))
	AddRegSetSME(m_opt_regsets.AnySet(eRegsetMaskZT));

If I apply the following patch then the "Sending vRun packet failed" error is gone but the client dumps what appears to be a bunch of unframed protocol data to the output stream. I also tried forcing eRegsetMaskSVE | eRegsetMaskSSVE in the regsets flag since these seem to be coupled. I'm a bit out of my element here though.

diff --git a/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp b/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
index c004c0f3c3cf..5c4f8f0d5e79 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
+++ b/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
@@ -275,7 +275,7 @@ RegisterInfoPOSIX_arm64::RegisterInfoPOSIX_arm64(
				AddRegSetTLS(m_opt_regsets.AllSet(eRegsetMaskSSVE));
			}

-      if (m_opt_regsets.AnySet(eRegsetMaskSSVE))
+      if (m_opt_regsets.AnySet(eRegsetMaskZA))
				AddRegSetSME(m_opt_regsets.AnySet(eRegsetMaskZT));

			if (m_opt_regsets.AllSet(eRegsetMaskFPMR))

Another curiosity I noticed is that the register flag eRegsetMaskZA is set, but never checked anywhere else:

llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp

Lines 128 to 132 in 5c45e23

	if (NativeProcessLinux::PtraceWrapper(PTRACE_GETREGSET,
	native_thread.GetID(), &regset,
	&ioVec, sizeof(za_header))
	.Success())
	opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskZA);

I tinkered around for a while and couldn't manage to get this working. @DavidSpickett do you have any insight here? Perhaps this is an issue in ptrace or some other oddity?

[gstelmack]

The SSVE note is interesting, I had to turn off SVE to get Java working in a docker container on Sequoia: https://medium.com/@luketn/java-on-docker-sigill-exception-on-mac-os-sequoia-15-2-9311e4775442. No idea if it's related.