Question:
Help Debugging Segmentation Fault(core dump) in C++?
ekkabahh
2016-03-21 17:22:25 UTC
I need to find a way to find the source of my problems in my C++ program. It compiles, and runs, but at one certain place, I get a segmentation fault. I have read about debuggers but can't get anything to work properly.

Is there an analytical way to approach this? Like, start with the pointers and make sure they are all set to NULL when declared? or something like that? I'm not even sure what to look for.
Three answers:
husoski
2016-03-21 18:01:46 UTC
A debugger helps, and the time to learn how to use one is when you are not under pressure to find an error quickly.



An alternative is to add diagnostic output statements to your code, showing values of key variables. The last output before the segment fault will tell you how far your code got before dying.



Another practice that helps is to include and insert assertions at key points in your code. These are boolean expressions that must be true if the program is operating properly. The assert macro will evaluate the expression and do nothing if it is true. If false, it will print a message identifying the assertion that failed, and then halt the program.

See: http://www.cplusplus.com/reference/cassert/assert/



The usual causes of segment faults are invalid pointers (failure to initialize, or failure to test for a NULL pointer returned from a function) and array index errors. Knowing that, you can take a critical look at your own code for that sort of problem. If you produced any output at all, maybe you know approximately where the error occurred, and that can let you narrow your search. Adding diagnostic outputs can help you refine that estimate.



PS: Initializing pointers to NULL will still cause segment faults if you try to use one without setting it to something else. However, doing that lets you add a test like:



if (ptr != NULL)

{

.... use the pointer

}

else

{

.... std::cout << "ptr==NULL in method my_class::xyz\n";

.... std::abort();

}



Asserts are easier:



assert(ptr != NULL && "NULL pointer in my_class::xyz");

... use the pointer only after the assert passed



That shows a sneaky way to get text into an assert output message. A failed assertion prints the expression along with the source file name and line number. A character string constant becomes a pointer in an expression, and a non-NULL pointer always evaluates as true. Only the ptr != NULL comparison matters, but the whole expression will be printed out.



Final note: The gdb debugger is easier to use in conjunction with an IDE like Code::Blocks, Eclipse, NetBeans or Dev-C++. If you use one of those, just start the program with debugging, and you should have a stack trace that shows what blew up, where that was called from, what called that, and so on. Make sure you're working with a Debug build instead of Release.
Sadsongs
2016-03-21 17:31:36 UTC
Initialise everything - it's good practice.



Then, follow each pointer. Is it assigned a value before use? Is the value correct? Is it pointing at what it should be? Check arrays - are they declared properly and values assigned? Are they correctly indexed in use (eg loop counters set to incorrect values)?





Have you looked at gdb? http://www.math.bas.bg/~nkirov/2005/netb151/debugging-with-gdb.html
Equinox
2016-03-21 17:37:41 UTC
1. download and install gdb

2. run your program under gdb

3. cause program to segfault

4. run the command 'bt' inside of gdb, it will point you right to where the segfault happened and the calls to get there


This content was originally posted on Y! Answers, a Q&A website that shut down in 2021.
Loading...