`lldb-server g $host:$port -- ./helloworld` on both MacOS and Linux on AArch64 crashes

[robertu94]

For Fedora 44 in a lima-vm.io VM:

[runderwood@lima-default build]$ lldb-server g 127.0.0.1:8000 -- ./helloworld
/usr/bin/../lib/gcc/aarch64-redhat-linux/16/../../../../include/c++/16/bits/stl_vector.h:1253: reference std::vector<unsigned int>::operator[](size_type) [_Tp = unsigned int, _Alloc = std::allocator<unsigned int>]: Assertion '__n < this->size()' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: lldb-server g 127.0.0.1:8000 -- ./helloworld
 #0 0x0000ffff9c819ce4 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib64/libLLVM.so.22.1+0x53a9ce4)
 #1 0x0000ffff9c81a768 (/lib64/libLLVM.so.22.1+0x53aa768)
 #2 0x0000ffffa332b928 (linux-vdso.so.1+0x928)
 #3 0x0000ffff96f71690 __pthread_kill_implementation (/lib64/libc.so.6+0x91690)
 #4 0x0000ffff96f1be5c gsignal (/lib64/libc.so.6+0x3be5c)
 #5 0x0000ffff96f06720 abort (/lib64/libc.so.6+0x26720)
 #6 0x0000ffff97269be8 (/lib64/libstdc++.so.6+0xa9be8)
 #7 0x0000aaaab48a2750 (/usr/bin/lldb-server+0xf2750)
 #8 0x0000aaaab48adb14 (/usr/bin/lldb-server+0xfdb14)
 #9 0x0000aaaab488b84c (/usr/bin/lldb-server+0xdb84c)
#10 0x0000aaaab488b368 (/usr/bin/lldb-server+0xdb368)
#11 0x0000aaaab488a030 (/usr/bin/lldb-server+0xda030)
#12 0x0000aaaab4914cb8 (/usr/bin/lldb-server+0x164cb8)
#13 0x0000aaaab485380c (/usr/bin/lldb-server+0xa380c)
#14 0x0000aaaab485c6a8 (/usr/bin/lldb-server+0xac6a8)
#15 0x0000ffff96f06f1c __libc_start_call_main (/lib64/libc.so.6+0x26f1c)
#16 0x0000ffff96f0705c __libc_start_main@GLIBC_2.17 (/lib64/libc.so.6+0x2705c)
#17 0x0000aaaab4851930 (/usr/bin/lldb-server+0xa1930)
Aborted                    (core dumped) lldb-server g 127.0.0.1:8000 -- ./helloworld

For MacOS 26.5 (25F71)

[runderwood@lima-default build]$ lldb-server g 127.0.0.1:8000 -- ./helloworld
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: lldb-server g localhost:8000 ./helloworld
#0 0x0000000102630a68 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x1000c0a68)
#1 0x000000010262e958 llvm::sys::RunSignalHandlers() (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x1000be958)
#2 0x00000001026310f0 SignalHandler(int) (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x1000c10f0)
#3 0x0000000182fdf744 (/usr/lib/system/libsystem_platform.dylib+0x1804fb744)
#4 0x000000010269b854 lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess() (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x10012b854)
#5 0x0000000102577390 handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&, llvm::ArrayRef<llvm::StringRef>) (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x100007390)
#6 0x0000000102578c8c main_gdbserver(int, char**) (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x100008c8c)
#7 0x000000010257ee14 main (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x10000ee14)
#8 0x0000000182c17e00
zsh: trace trap  lldb-server g localhost:8000 ./helloworld

The content of test.c is

#include <stdio.h>
int main() { printf("hello\n"); return 0; }

In the case of MacOS, I tried both the version of LLDB server provided by spack using their binary package cache. In the case of Fedora 44, I used the distribution provided packages.

I compiled test.c for Linux with GCC 16.1.1 (packaged with Fedora 44) and clang version 20.1.8,Target: arm64-apple-darwin25.5.0. I used $CC -g test.c -o ./helloworld

The underlying hardware is an Apple Macbook Pro, M5 Pro.

[llvmorg-github-actions]

@llvm/issue-subscribers-lldb

Author: Robert Underwood (robertu94)

Details

For Fedora 44 in a lima-vm.io VM:

[runderwood@<!-- -->lima-default build]$ lldb-server g 127.0.0.1:8000 -- ./helloworld
/usr/bin/../lib/gcc/aarch64-redhat-linux/16/../../../../include/c++/16/bits/stl_vector.h:1253: reference std::vector&lt;unsigned int&gt;::operator[](size_type) [_Tp = unsigned int, _Alloc = std::allocator&lt;unsigned int&gt;]: Assertion '__n &lt; this-&gt;size()' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: lldb-server g 127.0.0.1:8000 -- ./helloworld
 #<!-- -->0 0x0000ffff9c819ce4 llvm::sys::PrintStackTrace(llvm::raw_ostream&amp;, int) (/lib64/libLLVM.so.22.1+0x53a9ce4)
 #<!-- -->1 0x0000ffff9c81a768 (/lib64/libLLVM.so.22.1+0x53aa768)
 #<!-- -->2 0x0000ffffa332b928 (linux-vdso.so.1+0x928)
 #<!-- -->3 0x0000ffff96f71690 __pthread_kill_implementation (/lib64/libc.so.6+0x91690)
 #<!-- -->4 0x0000ffff96f1be5c gsignal (/lib64/libc.so.6+0x3be5c)
 #<!-- -->5 0x0000ffff96f06720 abort (/lib64/libc.so.6+0x26720)
 #<!-- -->6 0x0000ffff97269be8 (/lib64/libstdc++.so.6+0xa9be8)
 #<!-- -->7 0x0000aaaab48a2750 (/usr/bin/lldb-server+0xf2750)
 #<!-- -->8 0x0000aaaab48adb14 (/usr/bin/lldb-server+0xfdb14)
 #<!-- -->9 0x0000aaaab488b84c (/usr/bin/lldb-server+0xdb84c)
#<!-- -->10 0x0000aaaab488b368 (/usr/bin/lldb-server+0xdb368)
#<!-- -->11 0x0000aaaab488a030 (/usr/bin/lldb-server+0xda030)
#<!-- -->12 0x0000aaaab4914cb8 (/usr/bin/lldb-server+0x164cb8)
#<!-- -->13 0x0000aaaab485380c (/usr/bin/lldb-server+0xa380c)
#<!-- -->14 0x0000aaaab485c6a8 (/usr/bin/lldb-server+0xac6a8)
#<!-- -->15 0x0000ffff96f06f1c __libc_start_call_main (/lib64/libc.so.6+0x26f1c)
#<!-- -->16 0x0000ffff96f0705c __libc_start_main@<!-- -->GLIBC_2.17 (/lib64/libc.so.6+0x2705c)
#<!-- -->17 0x0000aaaab4851930 (/usr/bin/lldb-server+0xa1930)
Aborted                    (core dumped) lldb-server g 127.0.0.1:8000 -- ./helloworld

For MacOS 26.5 (25F71)

[runderwood@<!-- -->lima-default build]$ lldb-server g 127.0.0.1:8000 -- ./helloworld
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: lldb-server g localhost:8000 ./helloworld
#<!-- -->0 0x0000000102630a68 llvm::sys::PrintStackTrace(llvm::raw_ostream&amp;, int) (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x1000c0a68)
#<!-- -->1 0x000000010262e958 llvm::sys::RunSignalHandlers() (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x1000be958)
#<!-- -->2 0x00000001026310f0 SignalHandler(int) (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x1000c10f0)
#<!-- -->3 0x0000000182fdf744 (/usr/lib/system/libsystem_platform.dylib+0x1804fb744)
#<!-- -->4 0x000000010269b854 lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess() (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x10012b854)
#<!-- -->5 0x0000000102577390 handle_launch(lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS&amp;, llvm::ArrayRef&lt;llvm::StringRef&gt;) (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x100007390)
#<!-- -->6 0x0000000102578c8c main_gdbserver(int, char**) (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x100008c8c)
#<!-- -->7 0x000000010257ee14 main (/Users/runderwood/git/contrib/spack/opt/spack/darwin-m1/llvm-20.1.8-dh7t42sasa773qhsj72c3mz7jupalzlx/bin/lldb-server+0x10000ee14)
#<!-- -->8 0x0000000182c17e00
zsh: trace trap  lldb-server g localhost:8000 ./helloworld

The content of test.c is

#include <stdio.h>
int main() { printf("hello\n"); return 0; }

In the case of MacOS, I tried both the version of LLDB server provided by spack using their binary package cache. In the case of Fedora 44, I used the distribution provided packages.

I compiled test.c for Linux with GCC 16.1.1 (packaged with Fedora 44) and clang version 20.1.8,Target: arm64-apple-darwin25.5.0. I used $CC -g test.c -o ./helloworld

The underlying hardware is an Apple Macbook Pro, M5 Pro.

[DavidSpickett]

First thing is that lldb-server doesn't actually work on MacOS, assuming you are running it there - as opposed to connecting to it from MacOS. MacOS lldb -> lldb-server on Linux, this is fine. lldb-server's platform mode does work on MacOS but we really need to make it clear the gdbserver does not. For MacOS you need to use debugserver instead, which I expect is also included in the spack package.

Anyway we'll improve that (#199035). It's a far to common pitfall.

Can you give us:

• The version numbers of what you tried, and in which combinations (for example version X on Mac connecting to version Y on Linux, if applicable)
• The output you get on the lldb side, including the commands you entered. You can just copy paste the text from the session.

I have access to AArch64 Linux so I can try it out myself but I have a suspicion that...

M5 Pro.

This I believe has the Scalable Matrix Extension (SME), and until recently we had a bug where lldb-server would crash on startup #138717. The fix has not made it into an LLDB release yet, so it wouldn't be in the Fedora packages.

If you are able to configure the VM, try #138717 (comment) and see if that fixes it. The feature is passed from the host to the VM and there's no way I know in userspace to turn it off, you've got to hide it at the kernel level.

You can also use a version of lldb without any SME support.

From what will be the lldb 23 release notes:

Prior to this version of LLDB, there was a bug that caused LLDB to crash on startup on these systems (#138717). This affected LLDB versions from 18 up to and including 22. 17 and below are not affected. If you are using such a system and cannot change LLDB version, or want to package an affected version in a way that is compatible with these systems, the issue contains details of backports that could be done to fix the affected versions.

So you could try lldb 17 if you are not already using <= 17. I guess you are on 22 (https://packages.fedoraproject.org/pkgs/llvm/lldb/).

If you can't go back that far with the package manager, you can use a Github release - https://github.com/llvm/llvm-project/releases/tag/llvmorg-17.0.6

If you have no need to debug SME code specifically, you won't notice a difference. If you do, I can help you build your own copy of lldb.