Segfault

From C

Why Segfaults Are Useful

Before you read this, please read C FAQ 16.8.

At first glance, one may be very upset when one receives a segfault. Once one understands a segfault, it is more of a blessing. Of all the things that could happen when something goes wrong, a segfault is really the most informative and often the easiest to correct.

For starters, the C standard does not actually state that certain operations will cause a segfault; it merely says that some things have undefined behavior. Now what is undefined behavior? Exactly what it states really -- anything could happen. Your program could run fine, it could segfault, or it could corrupt part of itself. If it did corrupt itself the problems might not become evident for some time, causing quite a bit of head scratching when it finally does. Different architectures and C implementations will cause different things to happen for certains kinds of undefined behavior. For instance, on MS-DOS systems, dereferencing NULL did not necessarily cause the program to fail. On UNIX systems, an exception is raised causing a signal to be sent which usually terminates the program.

So why is your program segfaulting a good thing? Because it tells you that there is a problem. Of the choices available, your program crashing may be the best thing possible as it prevents further corruption and often provides information needed to solve the problem. If your program were to run as if there was no problem, then you have no way of identifying that there is a problem, which could easily create a show-stopper when someone runs your program on another architecture. It is usually harder to diagnose if your program appears to run fine, but later corrupts its data or mysteriously crashes. At that point it can be hard to determine the cause of the problem.

If your program is segfaulting you have a few choices as to how to handle it. For starters, you most likely want to run your program in a debugger until you receive a segfault. You can then diagnose the problem. A common starting point is a backtrace. If using GDB see backtrace. GDB is available for most common architectures and operating systems as well as a number of uncommon ones.

Another solution is to run your program in valgrind. Valgrind runs your program in a virtual machine, which informs when a read or write to invalid memory is attempted. It is a helpful tool for diagnosing strange behavior in your program. Valgrind requires linux/x86 (or an emulation of same), but there are several ports in the works.

If your application has random crashes at random times which are difficult to reproduce, a coredump can be handy. How you enable them depends on your system. On UNIX-like systems, use the shell's limit or ulimit command; the command in a Bourne-based shell (such as bash) is: ulimit -c unlimited, to allow a coredump of unlimited size. Now when your application crashes it will write a file containing all of the information about its state when it crashed, which you can load into a debugger and access a backtrace.

If you feel the need to force the termination of your program, you can call abort(), and on UNIX like systems a coredump may be written. You may also be able to use signal() or, preferrably, sigaction() to catch the SIGSEGV signal and perform actions when a segfault is signalled. But be wary of this as your application's state is in serious question and even mundane things may no longer be possible.

A final solution to avoid segfaults is simply not to use a language which allows you to have unrestricted access to your applications memory. C's very nature makes it relativly unsafe -- in order that it be as flexible as possible. Languages such as Python, Java, Ruby, Common Lisp and SML do not suffer from these problems nor have the (sometimes unneeded) flexibility. These languages have their own issues, and programming an application in several languages is becoming more common. Logix aims to unify this a bit more by allowing one to jump between languages easily.

All in all, consider a segfault A Good Thing since it will help you find problems in your code.