Differences

This shows you the differences between two versions of the page.

--- haas:spring2015:common:intro-to-gdb [2015/04/04 14:41] – [Setting a breakpoint] wedge
+++ haas:spring2015:common:intro-to-gdb [2015/04/04 15:00] (current) – [Viewing program data] wedge
@@ Line 193: / Line 193: @@
 =====Viewing program data=====
+Now it is time to take a look at what is actually going on. We THINK we know what is going on, but clearly what we think and what is actually are two different things (we think there shouldn't be a segfault, yet there is).
+So, looking at our suspect line:
+<code c>
+              stuff -> val = hi;
+</code>
+Let us see what the states of these variables are.
+====printing values during debug====
+To check the current state of a variable, we can use the **print** or **display** command to gdb.
+**print** will do a one time display of the state of a variable.
+**display** will set a display point, printing that variable state out after any further gdb commands (very useful for watching a loop play out)
+For now, let us take a look at both the **hi** and **stuff -> val** variables:
+<cli>
+(gdb) print hi
+$1 = 111 'o'
+(gdb) print stuff -> val
+$2 = -1991643855
+(gdb) print stuff
+$3 = (struct thing *) 0x4004d0 <_start>
+</cli>
+That value of **hi** should make sense (it should be set to the highest character value encountered during execution (user input)... if you typed in "hello", the 'o' would have the highest numerical value, based on its placement in the ASCII table.
+The stuff struct prints out seemingly random stuff. But we know that it is a pointer, and we didn't initialize it, so we're seeing whatever initial garbage values were at that memory location.
+Nothing seemingly out of place... let's check out the **stuff** variable itself:
+<cli>
+(gdb) print stuff
+$3 = (struct thing *) 0x4004d0 <_start>
+</cli>
+Even that seems okay... it is a pointer, it should have an address.
+Okay, so everything seems in order... let's try executing this line (and just this one line) and see what happens.
+=====Single-Stepping=====
+The debugger allows us to 'single step' through code, executing instructions individually. This is quite valuable as we can watch the state of our variables change, to better inform us as to what is going on.
+There are 2 stepping commands:
+  * **s**tep: execute the next instruction
+  * **n**ext: execute the next instruction, but do not descend into any called functions
+The **step** command lets us follow the thread of program execution, whereever it may lead. This can have its uses, but we have to be careful, we can only go where there is debugging support- while we compiled our program with debugging support, we linked against a non-debug C library. So any of those functions (**fgetc()**, **fprintf()**) we do **NOT** want to step into.
+When faced with a function call without debug symbols, or we simply do not wish to follow the thread of execution into that function, we can instead opt to step over it as if it were just a simple instruction. This is where the **next** command comes in handy.
+Let us execute that variable assignment, by issuing a **step** command:
+<cli>
+(gdb) n
+Program received signal SIGSEGV, Segmentation fault.
+x0000000000400682 in main () at input.c:23
+              stuff -> val = hi;
+(gdb)
+</cli>
+Everything seemed fine, but then when we tried to run it, bam- segfault.
+So something is clearly awry here.
+Knowing what those two variables are, **hi** likely isn't the problem, it is just a regular scalar variable.
+But **stuff** is a pointer. We know that when using pointers, we open the door to these kinds of problems.
+So what might the problem be?
+=====Solution=====
+This solution requires knowledge of the program itself-- its purpose, and the code contained therein. So clearly, if you aren't familiar with the code, not even the debugger can help you get to some solutions.
+In this case, the problem was that while we declared **stuff** as a pointer to a thing struct, we neglected to **allocate** memory, or point it at an existing instance of a thing struct.
+Adding this line up top would clear up the problem:
+<code c>
+stuff = (struct thing *) malloc (sizeof (struct thing));
+</code>
+Also what could have helped better identify this problem would have been to initialize **stuff** to NULL (one should ALWAYS set their variables to sane initial values).. setting it to NULL would have shown **stuff** to have been NULL, so there would NOT have been a **val** element to access (which would have caused a segfault).
+As it was, **stuff** WAS pointing somewhere, but an invalid location... so trying to modify the data there resulted in the operating system yelling at us.
+Seeing the NULL would have better clued us in that we had forgotten to **malloc()** the space, and could have more easily come to that solution. As it was, we had to do a little bit of detective work to eventually figure out it was the lack of memory allocation (and default invalid pointing of pointer) that created our problem.

Lab46 Wiki

User Tools

Site Tools

Differences

Page Tools