By this point nothing is displayed anymore and the process won’t stop until i do.
By the way i use a WSL (windows subsystem for linux) which is ubuntu and i used this command in order to install lldb :
sudo apt-get -y install lldb
I hope that someone could help me, I would be very grateful for that 
If there is a mod around, please add the lldb tag to this.
I take this to mean: until you interrupt it, with ctrl-c for example.
First check that the program runs to completion outside of the debugger. Ideally you would add some visible output like a print, just to be sure.
It it takes forever outside the debugger, then either there is a compiler issue creating an invalid program, or perhaps you have anti-virus that is causing a slowdown (though I don’t know how those interact with WSL, if at all).
If it works outside of LLDB then we would need to know what happens when you interrupt the program (or, as it may turn out, LLDB itself). Does it return to the (lldb) prompt or all the way back to the command line where you first ran LLDB?
What sort of time are we talking about here as well, are you waiting minutes and not getting any output? To be clear, it should not take that long but in rare circumstances it can.
But this would be something like debugging an OS kernel with all the optional debug information enabled. 99% of programs shouldn’t have a problem.
Oh and since you’re in WSL, you probably have gdb or the ability to install that?
If it has the same symptoms then there’s something going on that’s not under the debuggers’ control.
Can you show us a full debug session. For instance, when you ran the b main command, what did lldb say in return?
And as David asked, please show us what lldb says if you interrupt the process running with a ^C and run the bt all command.
I’d change the -g3 to -g, and add -O0. That way you get no optimization.
My (very vague) understanding of WSL is that it’s sort of like wine – runs user code natively and emulates/translates the syscalls. If so, then it’s quite possible that WSL doesn’t emulate the syscalls we use for debugging (ptrace) as they’re not necessary to run “normal” applications, or that its implementation has some subtle differences (there are plenty of those in ptrace) that are throwing lldb off.
It’s pure speculation though, I have no experience with WSL.
Get Started with C++ and Windows Subsystem for Linux in Visual Studio Code suggests that GDB does work. Which doesn’t mean it doesn’t have modifications to allow that.
Let’s see what OP finds, I can find a machine to install WSL if it turns out to be something unique to lldb.
ctrl-c is not working, the only way that i found to interrupt the process was to press random keys.
I made a simple program in order to test lldb :
#include <stdio.h>
int main(int argc, char **argv)
{
int i;
i = 1;
if (argc == 1)
return(-1);
while (argv[i])
{
printf("%s$\n", argv[i]);
i++;
}
return (0);
}
It’s running without any issues outside of the debugger
One time, i let it run for almost an hour and nothing happened, still the same outcome.
I tried with gdb and it shows me a warning everytime that I run it
warning: opening /proc/PID/mem file for lwp 1961.1961 failed: No such file or directory (2)
When I add a breakpoint it works
(gdb) b 20
Breakpoint 1 at 0x8001163: file test.c, line 20.
but when I run gdb I get an other warning
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x8001169
I don’t know if the warning of gdb will really help you
c - Troubleshoot lldb on Ubuntu (WSL) - Stack Overflow seems like the same situation and there are issues like gdb not able to debug · Issue #8516 · microsoft/WSL · GitHub and [WSL1] Cannot debug anything after upgrading to 22.04 · Issue #8356 · microsoft/WSL · GitHub. So this clearly has been a problem for others.
I installed WSL2 on a Windows on Arm machine running Windows 11 23H2. For Ubuntu Noble 24.04 and Ubuntu Jammy 20.04, GDB and LLDB installed via apt work fine. GDB does not complain about /mem/ either.
I then tried Ubuntu Noble in WSL1 and I could reproduce your issue:
# lldb main.o
(lldb) target create "main.o"
Current executable set to '/mnt/c/Users/tcwg/main.o' (aarch64).
(lldb) b main
Breakpoint 1: where = main.o`main at main.c:1:21, address = 0x0000000000000714
(lldb) run
Process 71 launched: '/mnt/c/Users/tcwg/main.o' (aarch64)
sdfsdfsdfsdfsdfdf
errwerwerewr
wer
werwProcess 71 exited with status = -1 (0xffffffff) lost connection
lldb talks to lldb-server, and lldb-server is the part that actually calls the debug APIs. So I looked at the logs for that. When it fails something is going wrong, but I can’t tell what. The breakpoint is placed correctly:
(lldb) b main
<...>
1738348179.135508537 NativeProcessProtocol.cpp:SetSoftwareBreakpoint addr = 0x8000714, size_hint = 4
1738348179.231178999 NativeProcessProtocol.cpp:EnableSoftwareBreakpoint Overwriting bytes at 0x8000714: 0x0, 0x0, 0x80, 0x52
1738348179.298000574 NativeProcessProtocol.cpp:EnableSoftwareBreakpoint addr = 0x8000714: SUCCESS
1738348179.356645584 Communication.cpp:Write 0x00007FFFC9497EA0 Communication::Write (src = 0x00007FFFC9497A20, src_len = 6) connection = 0x00007FFFC0F4F190
1738348179.421146154 ConnectionFileDescriptorPosix.cpp:Write 0x7fffc0f4f190 ConnectionFileDescriptor::Write (src = 0x7fffc9497a20, src_len = 6)
1738348179.498412848 Socket.cpp:Write 0x7fffc0f4ee00 Socket::Write() (socket = 13, src = 0x7fffc9497a20, src_len = 6, flags = 0) => 6 (error = (null))
Breakpoint 1: where = main.o`main at main.c:1:21, address = 0x00000000080007141738348179.545132637 ConnectionFileDescriptorPosix.cpp:Write 0x7fffc0f4f190 ConnectionFileDescriptor::Write(fd = 13, src = 0x7fffc9497a20, src_len = 6) => 6 (error = (null))
Then it never hits the breakpoint and interrupting the process fails:
(lldb) process interrupt
1738348372.668609142 Communication.cpp:Read this = 0x00007FFFDD884DB0, dst = 0x00007FFFDD8829E0, dst_len = 8192, timeout = 0 us, connection = 0x00007FFFD5FBC190
1738348372.716999054 ConnectionFileDescriptorPosix.cpp:BytesAvailable this = 0x00007FFFD5FBC190, timeout = 0 us
1738348372.780571938 Socket.cpp:Read 0x7fffd5fbbe00 Socket::Read() (socket = 13, src = 0x7fffdd8829e0, src_len = 1, flags = 0) => 1 (error = (null))
1738348372.826256752 ConnectionFileDescriptorPosix.cpp:Read 0x7fffd5fbc190 ConnectionFileDescriptor::Read() fd = 13, dst = 0x7fffdd8829e0, dst_len = 8192) => 1, error = (null)
1738348372.882876873 NativeThreadLinux.cpp:RequestStop NativeThreadLinux::RequestStop requesting thread stop(pid: 257, tid: 257)
1738348372.934549093 GDBRemoteCommunicationServerLLGS.cpp:Handle_interrupt stopped process 257
1738348372.968108654 Communication.cpp:Read this = 0x00007FFFDD884DB0, dst = 0x00007FFFDD8829E0, dst_len = 8192, timeout = 0 us, connection = 0x00007FFFD5FBC190
1738348373.011626482 ConnectionFileDescriptorPosix.cpp:BytesAvailable this = 0x00007FFFD5FBC190, timeout = 0 us
error: Failed to halt process: Halt timed out. State = running1738348392.690753222 Communication.cpp:Read this = 0x00007FFFDD884DB0, dst = 0x00007FFFDD8829E0, dst_len = 8192, timeout = 0 us, connection = 0x00007FFFD5FBC190
1738348392.759705782 ConnectionFileDescriptorPosix.cpp:BytesAvailable this = 0x00007FFFD5FBC190, timeout = 0 us
(1738348392.858328104 Socket.cpp:Read 0x7fffd5fbbe00 Socket::Read() (socket = 13, src = 0x7fffdd8829e0, src_len = 0, flags = 0) => 0 (error = (null))
l1738348393.011292458 ConnectionFileDescriptorPosix.cpp:Read 0x7fffd5fbc190 ConnectionFileDescriptor::Read() fd = 13, dst = 0x7fffdd8829e0, dst_len = 8192) => 0, error = (null)
l1738348393.153278828 Communication.cpp:Disconnect 0x00007FFFDD884DB0 Communication::Disconnect ()
d1738348393.293807507 ConnectionFileDescriptorPosix.cpp:Disconnect 0x7fffd5fbc190 ConnectionFileDescriptor::Disconnect ()
b1738348393.403239965 Socket.cpp:Close 0x7fffd5fbbe00 Socket::Close (fd = 13)
)
lldb-server exiting...
Which is not much use to anyone, but there it is to show this is real 
Weird thing is, GDB does work despite the /proc/mem warning:
(gdb) b main
Breakpoint 1 at 0x714: file main.c, line 1.
(gdb) run
Starting program: /mnt/c/Users/tcwg/main.o
warning: Unable to determine the number of hardware watchpoints available.
warning: Unable to determine the number of hardware breakpoints available.
warning: opening /proc/self/mem file failed: No such file or directory (2)
warning: opening /proc/PID/mem file for lwp 129.129 failed: No such file or directory (2)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main () at main.c:1
1 int main() { return 0; }
Perhaps this version of GDB knows to fall back from /mem to ptrace for writing memory.
LLDB I think is always using ptrace, but there must be a second problem it encounters.
So yeah, try WSL2 if you can. Remember to set your distro to use it wsl --set-version Ubuntu 2. If you cannot upgrade, then a different version of GDB may work. The one above is the Ubuntu Noble gdb/noble,now 15.0.50.20240403-0ubuntu1 version from apt. Or you can build it from source.
I will raise an issue in our tracker for this, but mostly so we can refer to it in future. I don’t expect that the issue will get fixed any time soon, especially if Microsoft considers WSL1 as legacy.
(I’m not personally saying that it is, in fact, today was the first time I’ve used WSL, so I have some research to do!)
Off topic, but I’m also unsure that this is reliable. Generally I’ve seen people use argc as the limit for how far to walk argv, but I’m not able to cite anything to say whether argv has a terminating element or not.
(this has no bearing on debugging though, main starts before any of that code)
I tried with wsl2 and it works perfectly. Thank you so much, I thought iI would never be able to use lldb on my laptop
Have a nice day
Not quite won’t fix because WSL1 is still supported by Microsoft, but I don’t expect it to ever be fixed unless someone really needs WSL1 and wants to contribute to LLDB.
For anyone else, use WSL2.
LLDB uses ptrace for writing memory, but it uses /proc for some other things. We’re not really testing the scenario where the proc filesystem is unavailable, so I wouldn’t be completely surprised if something went wrong in this case.