The LLDB Debugger (LLDB) is the debugger component of the LLVM project. It is built as a set of reusable components which extensively use existing libraries from LLVM, such as the Clang expression parser and LLVM disassembler. LLDB is free and open-source software under the University of Illinois/NCSA Open Source License, a BSD-style permissive software license. Since v9.0.0, it was relicensed to the Apache License 2.0 with LLVM Exceptions. Current state LLDB supports debugging of programs written in C, Objective-C, and C++. The Swift community maintains a version which adds support for the language. It is known to work on macOS, Linux, FreeBSD, NetBSD and Windows, and supports i386, x86-64, and ARM instruction sets. LLDB is the default debugger for Xcode 5 and later. Android Studio also uses LLDB for debug. LLDB can be used from other IDEs, including Visual Studio Code, C++Builder, Eclipse, and CLion. Examples of commands An example session Consider the following incorrect program written in C: #include <stdio.h> int main(void) { char msg = "Hello, world!\n"; printf("%s", msg); return 0; } Using the clang compiler on macOS, the code above can be compiled using the -g flag to include appropriate debug information on the binary generated—including the source code—making it easier to inspect it using LLDB. Assuming that the file containing the code above is named test.c, the command for the compilation could be: $ clang -g test.c -o test And the binary can now be run: $ ./test Segmentation fault Since the example code, when executed, generates a segmentation fault, lldb can be used to inspect the problem: $ lldb test (lldb) target create "test" Current executable set to 'test' (x86_64). (lldb) run Process 70716 launched: '/Users/wikipedia/test' (x86_64) Process 70716 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffffff90) frame #0: 0x00007fff6c7c46f2 libsystem_platform.dylib`_platform_strlen + 18 libsystem_platform.dylib`_platform_strlen: -> 0x7fff6c7c46f2 <+18>: pcmpeqb xmm0, xmmword ptr [rdi] 0x7fff6c7c46f6 <+22>: pmovmskb esi, xmm0 0x7fff6c7c46fa <+26>: and rcx, 0xf 0x7fff6c7c46fe <+30>: or rax, -0x1 Target 0: (test) stopped. The problem occurs when calling the function strlen, but we can run a backtrace to identify the exact line of code that is causing the problem: (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffffff90) * frame #0: 0x00007fff6c7c46f2 libsystem_platform.dylib`_platform_strlen + 18 frame #1: 0x00007fff6c66b16a libsystem_c.dylib`__vfprintf + 8812 frame #2: 0x00007fff6c6911c3 libsystem_c.dylib`__v2printf + 475 frame #3: 0x00007fff6c668e22 libsystem_c.dylib`vfprintf_l + 54 frame #4: 0x00007fff6c666f72