Source string Read only

(itstool) path: sect3/para
309/3090
Context English State
Hang on a minute! How did <symbol>anint</symbol> get to be <literal>4231</literal>? Was it not set to <literal>5</literal> in <function>main()</function>? Let us move up to <function>main()</function> and have a look.
(gdb) <userinput>up</userinput> <lineannotation>Move up call stack</lineannotation>
#1 0x1625 in main () at temp.c:11 <lineannotation>gdb displays stack frame</lineannotation>
(gdb) <userinput>p i</userinput> <lineannotation>Show us the value of i</lineannotation>
$1 = 4231 <lineannotation>gdb displays 4231</lineannotation>
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>4231</literal>.
The <command>gdb</command> command displays the stack frame every time we go into or out of a function, even if we are using <command>up</command> and <command>down</command> 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 gdb
To examine a core file, start up <command>gdb</command> in the usual way. Instead of typing <command>break</command> or <command>run</command>, type
(gdb) <userinput>core <replaceable>progname</replaceable>.core</userinput>
If the core file is not in the current directory, type <userinput>dir /path/to/core/file</userinput> first.
The debugger should display something like this:
<prompt>%</prompt> <userinput>gdb <filename><replaceable>progname</replaceable></filename></userinput>
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc.
(gdb) <userinput>core <filename><replaceable>progname</replaceable>.core</filename></userinput>
Core was generated by `<filename><replaceable>progname</replaceable></filename>'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x7020796d.
#0 0x164a in bazz (anint=0x5) at temp.c:17
(gdb)
In this case, the program was called <filename><replaceable>progname</replaceable></filename>, so the core file is called <filename><replaceable>progname</replaceable>.core</filename>. We can see that the program crashed due to trying to access an area in memory that was not available to it in a function called <function>bazz</function>.
Sometimes it is useful to be able to see how a function was called, as the problem could have occurred a long way up the call stack in a complex program. <command>bt</command> causes <command>gdb</command> to print out a back-trace of the call stack:
(gdb) <userinput>bt</userinput>
#0 0x164a in bazz (anint=0x5) at temp.c:17
#1 0xefbfd888 in end ()
#2 0x162c in main () at temp.c:11
(gdb)
The <function>end()</function> function is called when a program crashes; in this case, the <function>bazz()</function> function was called from <function>main()</function>.
Attaching to a Running Program with gdb
One of the neatest features about <command>gdb</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>gdb</command>, use <command>ps</command> to find the process ID for the child, and do
(gdb) <userinput>attach <replaceable>pid</replaceable></userinput>
in <command>gdb</command>, and then debug as usual.
Now all that is needed is to attach to the child, set <symbol>PauseMode</symbol> to <literal>0</literal>, and wait for the <function>sleep()</function> call to return!
Using Emacs as a Development Environment
Emacs
Emacs is a highly customizable editor—indeed, it has been customized to the point where it is more like an operating system than an editor! Many developers and sysadmins do in fact spend practically all their time working inside Emacs, leaving it only to log out.
It is impossible even to summarize everything Emacs can do here, but here are some of the features of interest to developers:
Very powerful editor, allowing search-and-replace on both strings and regular expressions (patterns), jumping to start/end of block expression, etc, etc.
Pull-down menus and online help.
Language-dependent syntax highlighting and indentation.
Completely customizable.
You can compile and debug programs within Emacs.
On a compilation error, you can jump to the offending line of source code.
Friendly-ish front-end to the <command>info</command> program used for reading GNU hypertext documentation, including the documentation on Emacs itself.

Loading…

User avatar None

New source string

FreeBSD Doc / books_developers-handbookEnglish

New source string a month ago
Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks

Reset

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect3/para
Labels
No labels currently set.
Flags
read-only
Source string location
book.translate.xml:2252
Source string age
a month ago
Translation file
string