Does anyone know a good debugger for C++ segmentation errors on the Linux environment? It would be good enough if the debugger could trace which function is causing the error.
Also consider some techniques that do require from you code changes:
Run your app via valgrind memcheck tool. It's possible to catch error when you access wrong address (e.g. freed pointer, not initialized) - see here.
If you use extensievly stl/boost, consider compiling with -D_GLIBCXX_DEBUG and -D_GLIBCXX_DEBUG_PEDANTIC (see here). This can catch such errors as using invalidated iterator, accessing incorrect index in vector etc.
tcmalloc (from google per tool). When linking with it's debug enabled version, it may find memory related problems
Even more ...
GDB! what else is available on Linux?
Check this out for starting up with GDB, its a nice, concise and easy to understand tutorial.
GDB is indeed about the only choice. There are some GUI's but they are allmost all wrappers for gdb. Finding a segfault is easy. Make sure you compile with -g -O0 then start gdb with your program as argument.
In gdb type run
To start your program running, gdb will stop it is soon as it hits a segfault and report on which line that was. If you need a full backtrace then just type bt. To get out of gdb enter quit.
BTW gdb has a build in help, just type help.
Related
Using gdb with eclipse, I'm getting a segfault and none of my thread stacktraces contain my source files.
This is with SDL, I believe SDL is the threads >1, while Thread 1 is my only one.
gdb trace
using gcc flags -std=c++1y -O0 -ggdb3
Even before I had this issue, gdb always crashes when the program terminates normally when ran in debug mode. Don't know if related.
Although I have been able to figure out the approximate area in my code where it occurs by commenting things out; I would like to know what is wrong independent of code so that I can use gdb properly.
Edit: It was a newb mistake of creating non-copied shared_ptr. So the crash is caused by a double freeing. Still doesn't explain the useless debug info however.
I have (probably quite common) issue that my code crashes with:
unknown location(0): fatal error in "BaumIteration_OneDimensionCase": memory access violation at address: 0xfffffff8: no mapping at fault address
for an optimized build (-O3 in gcc under Linux), but works fine in a debug build. I tried to debug the release build, but it just doesn't give any useful information. What are the standard techniques to solve this issue?
In some other question someone suggested using valgrind. How do I use it in this particular circumstances (if this is the right way forward anyways...)?
As mentioned , there is some code bug , but it so happens that due to different code generated, memory addresses used, it does not show up in unoptimized, debug build.
Since you asked about valgrind, the specific valgrind tool you should use is memcheck. It does a run time analysis of the code. It sure would help to find any possible errors or warnings in heap errors like memory leaks, array overbound access(Read/write), double frees ...
If you are on Linux platform , this is how to run your binary under valgrind:
valgrind --tool=memcheck --leak-check=full --show-reachable=yes --log-file=valgrind-log.txt -v --track-origins=yes <your binary file>
Read more about valgrind memcheck here.
Also if possible and if you use g++ to build , add these compiler options to your build process:
-Wall -Wextra -pedantic -Wuninitialized
Analyze the errors/warnings thrown by g++. It might show possible cause of error.
Goodluck debugging!
It's probably a problem that exists even in the debug build, but due to memory layout and what is being corrupted, it probably doesn't show up. As start point look at all the dynamic allocations, frees, arrays, pointers, uninitialized variable!
If i face this problem I will reduce the code size step by step to see if the problem exists this way I can find the location which is causing problem!
Another option is Intel Inspector which has similar capabilities to Valgrind. It comes with parallel studio and is really good at tracking memory errors down and pointing right to the problems.
If you're working on the cheap that may be no help but we all use the intel compiler where I work so it was a dream to save a bunch of time vs trying to hunt this down otherwise
I'm really lost in here. Maybe some of you can point me to a right direction.
I'm developing a tool in ANSI C using GCC over MinGW. The tool is to be run only from command line. Probably only on windows machine. It elaborates some data locally and generates files for use by other programs. Basically it does a lot of math and a few file handling. Nothing really fancy. I didn't find it necessary posting the whole 1000+ lines here for examination...
I compile it with GCC -ansi making sure not even a single warning is present. Everything worked always well as the development evolved. But recently I started getting (almost) random segfaults. I checked for the last changes made, but found nothing. I removed the last changes completely coming back to when it perfectly worked. Still segfaults. I traced line by line. I went back to read and re-read the whole code searching for possible pointers/malloc errors. I simply can't find the reason for it to fail so often and so randomly.
So here is the strange thing - I compiled it with -g and run through GDB.
start MSYS
change dir where the program resides
$ gdb generatore.exe (the one compiled -g that fails)
$ run
And it perfectly works inside GDB. I went step by step. Line by line. Perfect. I tried stressing it with huge amounts of data. All works. Can't reproduce the error. But if the same executable is run from command line, it fails.
I suspect an unpredictable behavior with some pointer but I cannot find it anywhere.
Has anyone ever encountered anything similar? Where should I be checking? Also, I am not as familiar with GDB, since it runs smoothly, can I enforce the control somehow to find the reason it fails? Are any other free debugging solutions for windows you can advise me? How can I debug for unpredictable behaviors?
Thanks a lot for your attention,
maxim
There is a great free tool for catching all kind of runtime errors to do with pointers, memory allocations, deallocations, etc., which cannot be caught at compile time, so your compiler will not warn you about them: valgrind http://valgrind.org/. The problem is, AFAIK it doesn't run on Windows. However, if your program is pure ANSI C you should be able to build it and run it with valgrind on a Linux box.
I'm not 100% sure about it, but it should run OK in a virtual machine, so if you don't have a separate Linux computer you can try installing e.g. Ubuntu in Virtual Box or VmWare and try running your program with valgrind in it.
I am trying to debug a problem with an application on Linux. It tends to crash with SIGSEGV in random places at libstdc++.so or libstdc.so.
There seem to be no obvious race conditions anywhere, as the job in the thread I added is very isolated. But it still crashes almost all the time.
The application is compiled with g++ -c ... -pthread -D_REENTRANT, and linked with g++ -pthread -o ...
But it's still crashing almost all the time in one of the libstdc*.so functions. I have wasted a few days on trying to figure out what's wrong, but no go...
Does anyone have any tips? Is there a way to make sure libstdc*.so is compiled as thread aware? Any gdb commands that could help me? Debug heaps?
I'm working with Linux for only a few years, so I'm lost...
There are few things you should do :
run your application using hellgrind
run your application using valgrind's memory check
run your application using DRD
Write unit tests. Although they do not help much in finding problems with threads, they can help you greatly with finding wrong memory access problems.
Try using -g when compiling if you're not already, to get symbolic debugger info.
Do you get a core dumped? If so you can use gdb to load the core against the executable as follows:
gdb <my-exe> <my-core-file>
Once loaded (presuming you compiled with -g) you can use info threads to get a list of all the threads stacks and take a look at the thread which caused the problem. If you follow the stack trace which caused the seg fault back up from the libstdc++.so or libstdc.so it should be reasonbaly obvious what's happening. At least it will get you to the right area.
If you don't get a core, can you run your app within the debugger itself?
This technique is also very useful fo getting to the bottom of thread deadlocking: Simply attach to the process using:
gdb <my-exe> <my-process-id>
and look for the two threads which are locking each other.
When I debug my c++ program with gdb in linux? I compile with -g and in fact, I see a lot of information in the debugger but it keeps telling me that my program exits normally and doesn't show any errors.
When I just run my program though, it doesn't finish and shows that not everything is alright (one assertion in malloc.c failed).
I also had the case, that gdb and just running the program showed different error messages. errors are alwazys related to wrong pointers, memory accesses.
Same actually goes for valgrind. Is there the possibility that it is not possible to use valgrind? In particular if there are different processes and a shared library included?
Running it with valgrind by: valgrind --trace-children=yes prog1 gives me no errors (which I cannot be true), if I enable the suppressed errors by: valgrind -v --trace-children=yes prog1, I get warnings about redirection conflicts (don't seem like errors either).
The problem with buggy programs is that their behavior is undefined. They work sometimes, and crash at other times unpredictably.
Both Valgrind and GDB affect the program timing, and may hide race conditions (which could happen for both multithreaded and multiprocess programs).
In addition, GDB disables address-space randomization, making addresses in the program repeatable from run to run. That's usually what you want while debugging, but your crash may only manifest itself for particular random layout of shared libraries, and that layout may never happen under GDB.
Your best bet is to enable generation of core dumps (ulimit -c unlimited), run the program outside GDB and have it abort (failing assert calls abort). Once you have a core, debug it with GDB: gdb /path/to/your/executable core.
For the problems you've described, Valgrind is usually a better tool. If multiple processes are involved, you'll want to run valgrind with --trace-children=yes flag.
This could be a multithreading problem and gdb slows it down enough that your threads don't conflict. Also maybe the program is being run optimized? Does valgrind say everything is ok?
I would enable all warnings in the compilation with -Wall, so that gcc will warn you about uninitialized variables, and then run it inside valgrind. One of them should tell you the problem.