I have noticed a rash of questions lately that are essentially this: "My code has a segmentation fault. The code compiles, many tests pass, but I can't figure out the problem!"
If this is you, then you have a very serious deficit in your skill set! I cannot say this loud enough or often enough:
YOU NEED TO LEARN HOW TO IDENTIFY THE SPECIFIC LINE OF CODE CAUSING A SEG FAULT!!!
This is a critical skill that absolutely must be cultivated! Over time, all programmers are going to encounter seg faults and other problems that will be associated with a problem in a single line of code. The first step in fixing it is actually locating the problem! Not interpreting it, just locating it!!!!! If you can't do this, you're severely handicapping yourself!
There are two common methods to do this.
- Step through the code in a debugger.
- Strategically insert printf statements.
- Do Both! (OK, but there's still only 2.)
DEBUGGER:
You should practice with the debuggers, whether debug50 or gdb or something else. Now is the best time to do it because you're working with simple programs, code and bugs. The process is this:
- Set breakpoints at strategic points in the code.
- Run the code to the first breakpoint, then the second, etc., but noting which breakpoints you've passed. At some point, the code will fail. That means that the failing code is somewhere after the last breakpoint you were at (it could be that actual line) and the next breakpoint.
- Add more breakpoints between the last breakpoint that executed and the next one in the code. Repeat step 2. (You may want to remove earlier breakpoints to speed up the process.)
- Keep repeating steps 2 and 3 until you narrow the code down to a few lines of code. At that point, run to the last breakpoint that runs, and then execute the code one line at a time until it fails. That will tell you which line has the problem. (Remember, the highlighted line has not yet executed.) Use the step into, step through, and step over arrows. Get used to using them and understand what they do.
- When you find the offending line, then you can move on to figuring out WHY it is failing. For seg faults, it's usually because the code is trying to access memory that is off limit, or there's a pointer that points to null or an invalid address.
However, sometimes, a seg fault will not occur when code is run in a debugger, or it happens a line or two later. It's rare, but it does happen. The interaction of the code and the debugger can mask an error. If this is the case, or if your code is small, you may want to just use the printf method.
PRINTF
When the debugger doesn't work for you, or you just don't want to do that, there's the printf method. Simply put, you insert unique printf statements in strategic locations in the code. My personal preference is printf("ping x \n"); Replace the x with unique numbers sequentially through the code. On the first pass, use numbers that are multiples of 10 or 100 to start. Using the same logic described above, insert more printf statements in the code until you can bracket the offending/broken line of code with printf statements. The bad code will always be between the last printf that executes and the first one that doesn't. It's a simple process, but can be a little tedious.
Use whichever method that works for you. It's important to learn how to find bad code using a simple and straightforward method, and not just trying to guess and guess. While the line causing the seg fault may not be the actual problem, you'll at least know what vars and function calls are involved and you can backtrack from there!!
This is my advice, as a seasoned programmer. Everyone learning how to program simply must learn the skills involved in debugging code. That starts with identifying the offending line(s) of code. THEN, and only then, finding the underlying problem. The final step is the why - why the problem is happening. THAT's where you actually fix it. But you can't fix something until you find it!!!!!
If anyone has any additional advice or anything to add, please add comments and answers!!!! I welcome them.
Note to moderators: This is bordering on "against forum policy" about opinion based questions and answers, but it's a critical lesson for all programming students. On that basis, I would ask that it be left on the forum and any opinion answers or comments allowed to remain. thank you.
[EDIT] This video from Doug on debug50 will also be helpful.
https://www.youtube.com/watch?v=VtkMZjvvKaU&feature=youtu.be&t=850
[EDIT 2] You can also run the program with valgrind and let valgrind tell you which line is blowing up.
