We start with compiling simple2.c and running the corresponding executable with argument 100.
|
The program stops with a segmentation fault
(see gdb session) and we find the value of
n a bit strange. We Dive into and select the tab
Tools and there Create Watchpoint. We select an
Unconditional watchpoint, so the program will stop when the
content of the specified memory location is changed. Selecting a
Conditional watchpoint we could as well insert code snippets or
open other Totalview windows like the visualizer.
This first shot turns out to be not very helpful. n is an automatic variable which may be somewhere else in memory next time we execute the program. Indeed, it has changed from 0x7ffc49b114c to a different adress and we are back to the point there we started. Still we see a segmentation fault at the same line of code. |
Ok, we step back with help of the stack trace into main and find, that nmax is the variables name and that it is initialized in main. Now we set a breackpoint at the initialization by clicking on line number 22 and restart. The program stops and now we Dive into nmax and set again an Unconditional watchpoint.
After a Go from the toolbar (or simply the abbreviation g) the program stops immediately. Indeed, nmax is changed in line 22 to 100. Go again stops in the watchpoint at line 5. The array squares contains 10 elements and we set the squares[11] which happens to be at the same memory location as nmax. This explains the strange value of n in function add_it that causes the segmentation fault.
Thus the segmentation fault is the second error in the code but the only one indicated by the system thanks to a segmentation fault. The true error, the change of nmax in set_it, happens unrecognized.