What Is SIGSEGV and How Do We Fix It?

SIGSEGV is a signal sent by the operating system to a process indicating that the process has attempted to access memory that it shouldn’t. This kind of error is prevalent in low-level code – that deals directly with system code, for example. These days, SIGSEGV errors are rare because of improvements in modern programming languages that automatically handle memory management. But they can still happen in code like C or C++, where memory management isn’t automatic by default, though even in those languages, better libraries are making SIGSEGVs uncommon.

Anatomy of a SIGSEGV Error

It all starts when a program tries to access a restricted memory area. Every program is given access to a virtual address space, and if it tries to access memory outside of that, this is caught by the CPU’s Memory Management Unit or MMU. This system informs the operating system of the problem through an interrupt or an exception. The operating system then sends the SIGSEGV signal to the program in question.

When a program receives a SIGSEGV signal, it typically terminates with an error message. While developers can try and “catch” such errors and perform a cleanup, doing so can be dangerous, because a SIGSEGV error indicates severe memory corruption, and only certain “safe” functions can be used. So typically, this means the end of the program.

Where are SIGSEGVs Generated?

As mentioned earlier, trying to generate a SIGSEGV on modern programs is difficult, because these languages are structured to avoid them by default. So in order to demonstrate what a SIGSEGV error looks like, we’re going to have to resort to lower level languages like C.

Consider the following C code:

#include <stdio.h>

int main() {
    int *ptr = NULL;  // Create a null pointer
    printf("Accessing null pointer...\n");
    *ptr = 42;  // This will trigger a segmentation fault
    return 0;
}

In the above code, we first create a NULL pointer using:

int *ptr = NULL;

Initializing the pointer to NULL means that the pointer doesn’t point to an address. This usually means it points to “0”, which is either not mapped to any actual physical memory or is reserved by the operating system. So when we try and write to the address using:

*ptr = 42;

The MMU detects this as an illegal operation and notifies the operating system, which in turn sends a SIGSEGV signal to the program, causing it to terminate. When I compile and run the above code, here is what happens:

You can see that the printf statement “Accessing null pointer” works, but as soon as the system tries to execute the next line, it generates a SIGSEGV error and exits with the message “Segmentation fault (core dumped)”.

The above shows how severe such an error can be. The program is terminated with no questions asked and no further confirmation. The reason for this is that the consequences of a program trying to access memory that it shouldn’t access can be dire. And the safest thing to do in such situations is to simply shut it down. Without this drastic intervention, a program can end up either accidentally or maliciously compromising the entire operating system, steal sensitive data from other programs like passwords or API keys, and more.

Segmentation Doesn’t Exist anymore. But the Error Does

In the earlier days of memory management, memory used to be arranged into “segments” of varying lengths. So the “SIGSEGV” signal was originally referred to as a “Segmentation Fault”. However, these days segments are superseded by “pages”, which are of fixed length and confer a variety of benefits over the old system.

But even though we don’t have segments anymore, the SIGSEGV signal remains the same to preserve the continuity of older code and now refers more broadly to memory faults in general.

What Happens When Programs Aren’t Memory Restricted?

To show you how serious a segmentation fault is, let’s consider some scenarios of what happens when a program can access the memory allocated to another process.

Programs Crashing When Another Intrudes

You run many programs on your computer simultaneously, and each has its memory and context. For example, the browser on which you’re viewing this article probably has several tabs open with URLs on each of them. When you switch to say, a text editor like Notepad, make some changes to a note, and then return to your browser, you expect the tabs and content to stay the way you left them. This confidence is thanks to the strong enforcement of memory protection by the operating system.

Imagine if this didn’t happen. Imagine if your notepad application was able to write to any part of memory. You may find that it starts to overwrite your tabs and the content within them so that your browser application is no longer the same as when you left it. In reality, the consequences are likely to be far more catastrophic. It would lead to the browser crashing as the notepad application will likely interfere with a critical piece of code.

Security Issues

The first point was from the point of view of system stability. But it can get a lot worse than that. While memory protection prevents accidental overwriting of code and data, it also prevents deliberate reading and writing. Imagine in the above example, that instead of accidentally changing your browser contents, the notepad program can intentionally read the contents of your browser, including possible passwords, API keys, and other sensitive data.

You can imagine what kind of security nightmare can arise if a program can freely access the contents of any other program, or even the operating system itself! A process can install a keylogger, for example, into your operating system and then transmit that information back a malicious entity. The security implications of cross-memory contamination are horrifying. And debugging the problem is even more of a headache, as you won’t know when a pointer is overflowing, and more.

Taking Over Hardware

All hardware attached to your computer has its dedicated memory registers. Devices like disk management software, for example, constantly work in the background to ensure your system runs smoothly, and for this, it needs to maintain the integrity of its memory registers. If a process can freely write over this memory at will, it will cause severe problems with the integrity of data and disks. Or imagine if a program had access to the memory used by the keyboard peripherals, they would be able to know everything you type even when not actively using the malicious program.

SIGSEGV faults are responsible for more crashes and bluescreens than any other problem. They used to be more significant in the past with non-standardized hardware and bootleg CDs, but thankfully, they are less of an issue now.

Conclusion

The SIGSEGV fault, while originally developed for a time when segments were used to manage memory, is still incredibly relevant in today’s world, even though we now use the concept of pages. The need to protect the memory of one program from being overwritten by another process is an ongoing concern that impacts almost every Operating System and hardware operation. While modern programming languages take care of memory management and prevent casual SIGSEGV errors, older languages like C and C++ can still trigger them pretty easily, as shown in the first example.