LLDB always exits abnormally on local code

Question

Created Dec ’23

Replies 3

Boosts 0

Participants 3

I am building simple command-line programs in C. When I run LLDB on the command line on any such executable , even though I set a breakpoint in main, LLDB always runs to termination and reports an error. Below is an example:

~ % clang -Wall -g prog.c -o prog aviram@csaamdS278stma ~ % lldb prog (lldb) target create "prog" Current executable set to '/Users/aviram/prog' (x86_64). (lldb) breakpoint set --name main Breakpoint 1: where = progmain + 15 at prog.c:73:21, address = 0x0000000100003ebf (lldb) run Process 99926 launched: '/Users/aviram/prog' (x86_64) Process 99926 exited with status = -1 (0xffffffff) lost connection (lldb) ` Note that it says "lost connection" even though I am _ remote debugging. This happens with every executable I build._ Details: 2019 MacBook Pro (x86_64, Sonoma); Apple Clang 12.0.0 (downloaded with Xcode 15.0.1). Why is this happening and what can I do to debug my program (for real) using LLDB from the command line? Thanks.

Boost

Answer 1

chrism238 OP

Jan ’24

No solution, sorry, but I have exactly the same problem. I can debug successfully a local program on Sonoma 14.2.1 on an M2, but when trying to debug the same code/program on Sonoma 14.2.1 on a 2019 Intel i5, I repeatedly get the "lost connection" outcome after setting a breakpoint at main():

(lldb) target create "factorial"
Current executable set to '/Users/chris/src/showc/showc/src/factorial' (x86_64).
(lldb) br set -n main
Breakpoint 1: where = factorial`main + 22 at factorial.c:30:9, address = 0x0000000100000e96
(lldb) run
Process 85314 launched: '/Users/chris/src/showc/showc/src/factorial' (x86_64)
Process 85314 exited with status = -1 (0xffffffff) lost connection

The frequent suggestion of using settings set plugin.process.gdb-remote.packet-timeout 300 has no effect.

0

Answer 2

chrism238 OP

Feb ’24

Wondering if (anyone) has seen any progress with this? My situation is identical to af57aviram's - the sequence results in the same failure on Intel, but is successful on Silicon M2s. Thank you,

0

Answer 3

natersoz OP

Mar ’24

Your post is being reviewed and will be published if approved.

Good, at least someone will read it.

0