Occam's Razor applied to the jungle of debugging.

The question “why does my code not work?” is far too often accompanied by either too little or too much information. Neither facilitates good answers. Getting the amount of information right should be easy, but apparently isn't. This little flowchart might help.

The idea here is that you stop trying your code do whatever it was intended to do, and try to come up with code that displays that problem you just encountered, and does only that. You encounter a segfault when trying to store student data. Your mission is now no longer to enter student data (that is completely superfluous at this point, and can be slashed away ruthlessly, hence the term “Machete Debugging”). Your mission is to reproduce that segfault in as little code as possible.

The process of reducing the size of code necessary to reproduce the problem should result in you finding the problem yourself ~80% of the time – it is a highly educational process. Programming errors can usually be reproduced in no more than one screenful of code, and quite often less. Exceptions to this are Heisenbugs (memory corruptions and threading errors), which are notoriously difficult to reproduce outside their natural habitat.

And if, after having no more than a couple of lines left, you still have not understood what the problem is, those few lines will make an excellent example to add to your question on StackOverflow.

Once you understood the issue, either by sudden realization or by having it explained to you by the friendly people at SO, fixing it in your actual program should be very easy.