I normally use GDB (in Linux, with the Qt Creator debugger GUI) to debug. But right now I have a crash that refuses to ever happen when running under the debugger, yet happens easily when running outside of it.
How do I get a stack trace of my crash, in these circumstances?
A linux-specific solution is OK.
Note: I'm talking about running a debug build only, even when it's run outside the debugger.
The easiest way to be sure you can obtain a stacktrace after a crash is to run
ulimit -c unlimited
In your shell before starting the program.
This will ensure that the kernel is allowed to produce a "core dump" of unlimited size (for many distros the default size is 0) when a program crashes.
That core file can then be loaded into gdb as gdb programfile corefile and then the command thread apply all bt will give you stack traces for all threads for that specific crash (use just bt if you only care about the crashing thread).
You can also use the pstack program to get a stacktrace from a running program.
Related
I developed a project on Mac using C++. It works perfectly. However when I try to launch it from a Linux server, I get a bad alloc error:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
I don't know how to debug the whole project because I have absolutely no idea of where the issue come from. Why is it working on my Mac and not on Linux? All articles and questions about that only ask for single file program but not 40+ files project.
Is there a way to get the file or line that causes the bad alloc?
Build your program with the -g compiler option to get meaningful stack traces.
Then run the program in a debugger, e.g. gdb:
gdb --args [executable] [arguments...]
When gdb has loaded, enter the command run and you program will be run. As soon as the exception is thrown and not caught by your program, gdb will show you a stack trace showing you from where the exception was thrown.
std::bad_alloc means that your program wasn't able to allocate any more memory, probably because the OS either ran out of memory or you hit an explicit memory limit imposed by the system.
I have run my app for several hours, and it has crashed. (c++ app, on LINUX os)
I know that when running app via gdb, we can get the line code & reason of the crash.
But unfortunately I forgot to run it via gdb :(
Is there a way to get the reason of the crash ?
You can enable unlimited core dump sizes by
ulimit -c unlimited
This will write down a core file in case of a crash into the same directory from where you started the program. Afterwards you can load it with the gdb option --core.
I compile C++ code with MinGW GCC on Windows. I'm currently dealing with a SIGSEGV that occasionally pops up in a multithreaded program, so I can't really step through the program with GDB like I normally would. I've read through program logs but they only gave me an idea as to where the problem happened.
Can I get a stack trace of where the problem occurred? I saw a similar thread here but since I don't have execinfo.h I cannot use it.
You can run the program with gdb (command r). Where ever it crashes, you will get back to gdb and you can look at the stack trace and variables.
You may want to look at this also, or search for "gdb multithreaded".
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.
I'm building an application for Windows XP using the MinGW tool chain and it sometimes crashes unexpectedly. So, I'm trying to use a debugger (Gdb) but the program exits with code 03 before anything happens. In fact, all I see from GDB is:
[New thread 3184.0x7b8][New thread
3184.0xef8]
Program exited with code 03.
My suspicion is that there is some failed dynamic linking of a dependency (which are Qt, VTK, and ITK, all built with MinGW). However, this does not happen when I just run the program normally. Or if it happens, it appears to be intermittent and well after the program is launched and running. NOTE: I'm also using Cmake for cross compiling.
What should I do? What can I try?
Add a callback via signal(SIGABRT, <callback>) to catch the call to abort before it shuts down the process. If this happens before you hit main() you might have to resort to a static global and compiler trickery to catch it.
Code 3 is usually returned on a segfault.
Try switching to Linux and debugging the program with electric fence. It might give you some extra insight.