# A Minimal LLDB Guide for Investigating Crashes

DevFeed: [A Minimal LLDB Guide for Investigating Crashes](<https://devfeed.tech/articles/i-don-t-really-want-to-learn-lldb-i-just-want-to-fix-a-crash-35552.md>)

Original publisher: [Read original article](<https://meowni.ca/posts/unscary-lldb/>)

Author: Monica Dinculescu

Published: 2014-06-23T00:00:00Z

Content type: tutorial

Language: en

Sources: [Monica Dinculescu](<https://devfeed.tech/sources/monica-dinculescu.md>)

Topics: [debugging](<https://devfeed.tech/topics/debugging.md>), [Tooling](<https://devfeed.tech/topics/tooling.md>), [clang](<https://devfeed.tech/topics/clang.md>), [gdb](<https://devfeed.tech/topics/gdb.md>), [Chromium](<https://devfeed.tech/topics/chromium.md>)

Tags: [breakpoint](<https://devfeed.tech/tags/breakpoint.md>), [chromium](<https://devfeed.tech/tags/chromium.md>), [clang](<https://devfeed.tech/tags/clang.md>), [commands](<https://devfeed.tech/tags/commands.md>), [crash](<https://devfeed.tech/tags/crash.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [gdb](<https://devfeed.tech/tags/gdb.md>), [tutorials](<https://devfeed.tech/tags/tutorials.md>)

## AI overview

A concise tutorial on using LLDB to investigate program crashes. It covers launching an executable, reproducing a crash, reading a stack trace, and setting breakpoints, with Chromium debugging examples.

## Source excerpt

lldb stands for Llama-DB, and is a database of llamas you can use to debug programs compiled with clang (lldb is to clang like gdb is to gcc). If you already know how to use gdb, then here's a translation of the common commands. Disclaimer: There is a ton of tutorials and pages about all of the awesome features and commands of lldb, and how to become a debugging pro. This is not that. This is the smallest set of things you need to read to answer the question "what's making this shit crash". That's it. Step 1. Make it go If you want to pass a bunch of arguments to your executable moose, use (´ ▽｀).。ｏ♡ src on fix/moose-crash ☀ ❥ lldb -- moose arg1 arg2 Current executable set to 'moose' (x86_64). If you don't have arguments, lldb foo is enough. This just tells lldb which executable to care about, but it won't actually start the process for you. (lldb) run --> Start or re-start your process (lldb) exit --> Stop your process. Step 2. Make it crash Since we (me) are investigating a crash, the first thing you need is a stack trace that tells you where the crash is. So, start your process in lldb, make it crash, and we'll take it from there. Side bar: I literally typed this blog out while sorting out a crash in the sign-in bits of Chromium, so all my screenshots are Chromium code. Do not panic. Your code can crash just as well if you give it enough time and attention. Once you hit your crash, lldb tells you something like this. I can't tell you how excited I am at that little arrow. It almost looks non-intimidating. Almost. Step 3. Breakpoints! It's hammer time The first thing I did was set a breakpoint at that line to figure out what's going on right before things got crashy (because I'm sure you're dying to know, my crash was happening because we hit that DCHECK which reads "the item should always be signed in" and, spoilers, it isn't) To set a breakpoint in a file at a specific line: (lldb) breakpoint set --file profile_chooser_controller.mm --line 1509 Awesome discovery