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:


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.

  1. Step through the code in a debugger.
  2. Strategically insert printf statements.
  3. Do Both! (OK, but there's still only 2.)


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:

  1. Set breakpoints at strategic points in the code.
  2. 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.
  3. 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.)
  4. 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.
  5. 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.


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.

[EDIT 2] You can also run the program with valgrind and let valgrind tell you which line is blowing up.

  • 1
    Cliff, could you 1) change this to an answer and check community wiki 2) add specific advice about using a small data set (ie speller) and 3) IMO (of course) put a more positive spin on "very serious deficit in your skill set" eg "missing an important skill that will hinder progress as a programmer" Commented May 6, 2020 at 11:37
  • Hmmmm.... no. Normally, I try to put a positive spin on everything, but this one just doesn't get through. And lately, I'm seeing this more than everything else combined. It's just so frustrating to see!!! Smaller data sets? that's a completely different topic, and for speller, often doesn't produce errors that large data sets will. As for community wiki, I've never seen how marking something as a community wiki differentiates it from other posts (but I'll consider it.) And of course, your opinions, Dino, are still highly valued. I do appreciate your comments!
    – Cliff B
    Commented May 11, 2020 at 18:45
  • Unfortunately, debug50 doesn't exist anymore. Commented May 28, 2020 at 5:46
  • Well that's just not true. What makes you think that debug50 doesn't exist any more? Even if it doesn't, you should learn how to use a debugger like gdb. (BTW, debug50 is nothing more than a custom interface to gdb written by cs50 staff.
    – Cliff B
    Commented May 28, 2020 at 6:35
  • 1
    @CliffB: given StackExchange's Q&A format, it would be better if you posted most of your advice as an answer to your own question. (yes, you can do that!)
    – MestreLion
    Commented Nov 25, 2020 at 7:16

2 Answers 2


Reread the post again, he explains why the seg fault happens. A quick google should suffice too.


A better way to identify the source of segmentation faults is to compile with

-g -fsanitize=undefined -fsanitize=address

running the program should then point you to the exact line where the violation occurred. As well as info on what happened, like was it a read or write that caused the seg fault.

Not the answer you're looking for? Browse other questions tagged .