Let’s rock and roll. Below we have a C-program designed to accept and print command line arguments: accepts a string intended to be printed and a string that is converted to an integer using the function. However, this program intentionally contains a mistake. Notice the block of code written to check the number of command line arguments is commented out. This will result in a segmentation fault when the program attempts to access memory it does not have access to: Convert2.c atoi() We can explore this further with gdb: Notice the “where” command seems to display a execution stack Take a close look at this line: GDB is telling us that argv (which is a pointer to a list of strings) is pointing to some address . This is the beginning of the address of the first string in the list of strings. Let’s examine that memory: 0xbffff894 Each of the three hexadecimal words represents a command line argument (actually a pointer to a command line argument). The first argument is always the name of the executable file (in this case just “ ”) and the second argument in this case is “ ”. a.out test Since we have not supplied a third command line argument, we do not have access to the memory at address . When we try to access it in our source code with the line “ ” we get a segmentation fault. 0x00000000 count = atoi(argv[2]); This example highlights (indirectly) one other gdb tool that we haven’t discussed yet — “bt.” If you look two screenshots up where the “where” command was executed in gdb you’ll see a stack. You can use the bt utility to displays the state of the execution stack at any point. Let’s use an example program to illustrate this: calls which calls . Our execution stack would look like: Main() func1() func2() Notice this is what the stack looks like after we run “bt.”: The topmost frame is the one we are currently on. We can verify this by printing the value of n (in this value should be 30): func2() p is short for “print” We can also move from one frame to another — even if the current frame hasn’t finished executing: We can also get information about each frame by running “info frame”: Here we see that frame #2 which lives at calls frame #1 which lives at . 0x7fffffffe5a0 0x7fffffffe580 This is how we can use the bt utility to examine the execution stack in gdb and hopefully use it as a tool to track down segmentation faults.
