Why is my code showing a segmentation error

Are you determining which line of code is causing a segmentation error?

How can you tell where the error is in the code that is causing a segmentation error?

Can my compiler () show the location of the error in the program?


GCC can't, but GDB (a debugger) sure can. Compile your program with the switch as follows:

Then use gdb:

Here's a nice tutorial to get you started with GDB.

Where the segfault occurs is generally just an indication of where in your code "the fault that caused it" is. The location indicated is not necessarily where the problem is.

Or try: When you install and run

Your program will then be executed and stack traces will be displayed for all segfaults as well as for invalid memory reads or writes and memory leaks. It is really very useful.

You can also take a core dump and then examine it with gdb. To get useful information, you need to compile with the flag as well.

Whenever you get the message:

A core file will be written to your current directory. And you can check it with the command

The file contains the status of the memory when the program crashed. A core dump can be helpful during the deployment of your software.

Make sure your system is not zeroing the core dump file size. You can set it to unlimited with:

Attention! that core dumps can get huge.

There are a number of tools that will help with debugging segmentation errors, and I'd like to add my favorite tool to the list: Address Sanitizers (often abbreviated as ASAN) .

Modern¹ compilers come with the handy flag that adds some compilation and run-time costs, thereby checking for more errors.

According to the documentation, these checks include intercepting segmentation errors by default. The advantage here is that you get a stack trace similar to the output from gdb, but without running the program in a debugger. An example:

The output is a little more complicated than output from GDB, but there are advantages:

  • It is not necessary to reproduce the problem to get a batch trace. It is enough to activate the flag during development.

  • ASANs capture much more than just segmentation errors. Many accesses outside of the boundaries are intercepted even if this memory area was accessible to the process.

¹ These are Clang 3.1+ and GCC 4.8+.

Lucas' response to core dumps is good. In my .cshrc I have:

to display the tracing by entering 'core'. And the date stamp to make sure I'm looking at the correct file :(.

Added : Lies a stack Corruption error, then the backtrace applied to the core dump is often garbage. In this case, the program can be run within gdb lead to better results according to the accepted answer (provided the error is easily reproducible). Also make sure that multiple processes are draining the core at the same time. Some operating systems add the PID to the name of the core file.

All of the above answers are correct and are recommended. This answer is intended as a last resort only if none of the approaches above can be used.

If all else fails, you can always recompile your program with various temporary debug print statements (e.g.) spread out over what you think are relevant parts of your code. Then run the program and see what the last debug print was, printed just before the crash. You know your program has come this far. The crash must have taken place after this point in time. Add or remove debug printouts, recompile, and rerun the test until you have narrowed it down to a single line of code. At this point you can fix the error and remove any temporary debug printouts.

It's pretty boring, but it has the advantage that it works just about anywhere - the only time you can't access stdout or stderr for some reason, or when the bug you're trying to fix is ​​a racing -condition, theirs Behavior changes when the timing of the program changes (as the debug prints slow down the program and change its timing)

We use cookies and other tracking technologies to improve your browsing experience on our website, to show you personalized content and targeted ads, to analyze our website traffic, and to understand where our visitors are coming from.

By continuing, you consent to our use of cookies and other tracking technologies and affirm you're at least 16 years old or have consent from a parent or guardian.

You can read details in our Cookie policy and Privacy policy.