Source string Read only

(itstool) path: sect3/screen
Context English State
Oh dear! Looking at the code, we forgot to initialize <symbol>i</symbol>. We meant to put
main() {
int i;

i = 5;
printf("This is my program\n");
but we left the <literal>i=5;</literal> line out. As we did not initialize <symbol>i</symbol>, it had whatever number happened to be in that area of memory when the program ran, which in this case happened to be <literal>-5360</literal>.
The <command>lldb</command> command displays the stack frame every time we go into or out of a function, even if we are using <userinput>up</userinput> and <userinput>down</userinput> to move around the call stack. This shows the name of the function and the values of its arguments, which helps us keep track of where we are and what is going on. (The stack is a storage area where the program stores information about the arguments passed to functions and where to go when it returns from a function call.)
Examining a Core File with lldb
A core file is basically a file which contains the complete state of the process when it crashed. In <quote>the good old days</quote>, programmers had to print out hex listings of core files and sweat over machine code manuals, but now life is a bit easier. Incidentally, under FreeBSD and other 4.4BSD systems, a core file is called <filename><replaceable>progname</replaceable>.core</filename> instead of just <filename>core</filename>, to make it clearer which program a core file belongs to.
To examine a core file, specify the name of the core file in addition to the program itself. Instead of starting up <command>lldb</command> in the usual way, type <userinput>lldb -c <replaceable>progname</replaceable>.core -- <replaceable>progname</replaceable></userinput>
The debugger will display something like this:
<prompt>%</prompt> <userinput>lldb -c <filename><replaceable>progname</replaceable>.core</filename> -- <filename><replaceable>progname</replaceable></filename></userinput>
(lldb) target create "<filename><replaceable>progname</replaceable></filename>" --core "<filename><replaceable>progname</replaceable></filename>.core"
Core file '/home/pauamma/tmp/<filename><replaceable>progname</replaceable>.core</filename>' (x86_64) was loaded.
In this case, the program was called <filename><replaceable>progname</replaceable></filename>, so the core file is called <filename><replaceable>progname</replaceable>.core</filename>. The debugger does not display why the program crashed or where. For this, use <userinput>thread backtrace all</userinput>. This will also show how the function where the program dumped core was called.
(lldb) <userinput>thread backtrace all</userinput>
* thread #1, name = '<filename><replaceable>progname</replaceable></filename>', stop reason = signal SIGSEGV
* frame #0: 0x0000000000201347 <filename><replaceable>progname</replaceable></filename>`bazz(anint=5) at temp2.c:17:10
frame #1: 0x0000000000201312 <filename><replaceable>progname</replaceable></filename>`main at temp2.c:10:2
frame #2: 0x000000000020110f <filename><replaceable>progname</replaceable></filename>`_start(ap=&lt;unavailable&gt;, cleanup=&lt;unavailable&gt;) at crt1.c:76:7
<literal>SIGSEGV</literal> indicates that the program tried to access memory (run code or read/write data usually) at a location that does not belong to it, but does not give any specifics. For that, look at the source code at line 10 of file temp2.c, in <function>bazz()</function>. The backtrace also says that in this case, <function>bazz()</function> was called from <function>main()</function>.
Attaching to a Running Program with lldb
One of the neatest features about <command>lldb</command> is that it can attach to a program that is already running. Of course, that requires sufficient permissions to do so. A common problem is stepping through a program that forks and wanting to trace the child, but the debugger will only trace the parent.
To do that, start up another <command>lldb</command>, use <command>ps</command> to find the process ID for the child, and do
(lldb) <userinput>process attach -p <replaceable>pid</replaceable></userinput>
in <command>lldb</command>, and then debug as usual.
For that to work well, the code that calls <function>fork</function> to create the child needs to do something like the following (courtesy of the <command>gdb</command> info pages):
if ((pid = fork()) &lt; 0) /* _Always_ check this */
else if (pid == 0) { /* child */
int PauseMode = 1;

while (PauseMode)
sleep(10); /* Wait until someone attaches to us */
} else { /* parent */
Now all that is needed is to attach to the child, set <symbol>PauseMode</symbol> to <literal>0</literal> with <userinput>expr PauseMode = 0</userinput> and wait for the <function>sleep()</function> call to return.
Remote Debugging Using LLDB
The described functionality is available starting with LLDB version 12.0.0. Users of FreeBSD releases containing an earlier LLDB version may wish to use the snapshot available in <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/handbook/ports-using.html">ports or packages</link>, as <package>devel/llvm-devel</package>.
Starting with LLDB 12.0.0, remote debugging is supported on FreeBSD. This means that <command>lldb-server</command> can be started to debug a program on one host, while the interactive <command>lldb</command> client connects to it from another one.
To launch a new process to be debugged remotely, run <command>lldb-server</command> on the remote server by typing
<prompt>%</prompt> <userinput>lldb-server g <replaceable>host:port</replaceable> -- <replaceable>progname</replaceable></userinput>
The process will be stopped immediately after launching, and <command>lldb-server</command> will wait for the client to connect.
Start <command>lldb</command> locally and type the following command to connect to the remote server:
(lldb) <userinput>gdb-remote <replaceable>host:port</replaceable></userinput>
<command>lldb-server</command> can also attach to a running process. To do that, type the following on the remote server:
<prompt>%</prompt> <userinput>lldb-server g <replaceable>host:port</replaceable> --attach <replaceable>pid-or-name</replaceable></userinput>
Using gdb


User avatar None

New source string

FreeBSD Doc / books_developers-handbookEnglish

New source string 6 months ago
Browse all component changes


English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect3/screen
no-wrap, read-only
Source string location
String age
6 months ago
Source string age
6 months ago
Translation file
books/developers-handbook.pot, string 360