You need to isolate which line of code is causing this error. You could do this by running it in debug50 or by strategically placing some printf statements to find which lines are executing and what is the first line that isn't being processed. Sometimes, debug will mask an error. When you can't reproduce it in debug, but can reproduce it when normally executing, it's time to use the printf technique.
Once you find which line is failing, it should be obvious what the specific problem is that causes this error. However, you'll have to start thinking about what the underlying problem is and solve that!
I could tell you what's happening, but you'll benefit more from doing it yourself. The process will help develop and refine your debugging skills, one of the most important things you can do!
If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)
Well, it looks like several people didn't like my answer here. Let me say this. This is a teaching forum, and therefore different from most of Stack Exchange. It's vastly more important for new programmers to learn how to identify which lines of code causes a seg fault than to simply resolve the problem.
Coding errors like Seg faults and other failures will occur constantly over a programmer's career. If they can't locate exactly which lines of code are causing them, then the programmer is seriously handicapped because they haven't developed that skill. THAT'S why I responded as I did!
That's why my philosophy is to teach this skill first! Once someone is able to identify a line of code that causes a problem, only then is it appropriate to move on to why a problem is happening.
There's one more difference. Identifying an offending line of code is a skill that absolutely must be developed through practice and repetition. It's an intrinsic skill that must be cultivated. Once a line of code is identified as being the source of a bug, then it's usually a matter of an incorrect usage of something or some other tech issue. Most often, this is the kind of error that can simply be explained, rather than asking the person to try to discover the problem. Frequently, it's something they've done that's incorrect, but they've never been shown what is wrong. Once the issue is described, it's usually remembered. Over time, with different issues, the programmer will learn to recognize different classes and types of problems and how to resolve them.
For example, a very common problem is this:
If this were in someone's code, it would surely throw a seg fault. But most people don't know why until it's explained to them. If someone says "I can't find the seg fault, can you help?" then they clearly need practice to locate which code would be causing a seg fault. OTOH, if they said, "I'm getting a seg fault from this call to isdigit and I don't know why!" then it's clear that they identified the code that is causing the problem and it's only necessary to expose them to the cause of the seg fault once. They'll never forget it!. (Incidentally, this could be caused by two different issues. ;-) )
The point of all this is that identifying the offending code is a must-learn skill, while resolving the issues, once identified, is more about seeing the resolution once and remembering it.
Of course, the next phase is learning to deal with deeply buried logic bugs, but that's an entirely different skill. ;-)