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.
Related
This is probably a very basic question. However, I couldn't find any answer by searching the web.
I have a code I need to debug written in C++. For this code, I require to use GCC 4.1.2 in compatibility reasons and I am using GDB 6.6-45. I compiled the code with the -g -Wall -O0 flags to make sure the code can be debugged with GDB.
My problem is that wherever I set the breakpoint, no breakpoints get hit. Also, at the end of the run, I get this message "You can't do that without a process to debug".
By the sound of the message, I think I am missing a very trivial thing. However, I cannot figure out.
Any help would be appreciated.
EDIT:
The platform I am working on is Fedora 8 on VirtualBox. The reason why I am working on VirtualBox is because I wasn't good enough to install older version of GCC (4.1.2) properly without breaking Fedora 20, which is the latest.
As per GDB output, (it's very basic):
[localhost]$ gdb programName
GNU gdb Red Hat Linux (6.6-45.fc8rh)
... typical messages
This GDB was configured as "i386-redhat-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run programName (program arguments here)
...
Program outputs and messages
...
Program exited normally.
You can't do that without a process to debug.
(gdb)
What's shown above is all I have. To set my breakpoints, I did something similar to:
break main
break System::function_name
break System::line_number
and when I run info breakpoints, the breakpoints does show correct cpp file and the line number or the function name, with enabled flag to yes.
If possible try to avoid -O flag and just use -g -Wall only. I have seen some problems with -O flag in older versions. But I'm not sure whether they persist in novel gcc as well. Just give it a try.
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.
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.