Ubuntu 10.10, GDB 7.2.
I attach to an application, watch stacks in every thread, everything looks good. Do generate-core-file and try to open that coredump in gdb. No routines is shown in backtraces.
I send SIGSEGV to the application and open this new coredump in gdb. Stacks are ok and verbose.
Please tell me if you experienced a similar incorrect behaviour of generate-core-file.
This is a known bug in GDB. The link has also a patch for fixing the problem.
Related
Having one heck of a time debugging a crash in a Windows Service that I've build with QT and Boost Logger on Windows using MSYS2 environment. The main issue really comes when I stop the program right before exit. The program just doesn't exist successfully and throws one of these bad boys:
If I was running it in gdb it might be a different story. I open the crash dump in windbg and get some info, but since the symbols aren't exported it's really cryptic.
I see some issues when my program (called service) is calling the log. But I can't do much here in the way of where or what. How can I get something useful so I could finally solve this issue?
Thanks so much!
Seems like the easiest and most natural way was to attach gdb to the running process. I simply ran msys2 as Administrator, then ran the command
gdb service.exe -p [processID]
Task manager gave me the process ID. As soon as the process was attached I just used the command
continue
to get it to continue running. Then I let it crash and gdb gave me the backtrace perfectly.
I've searched a bit for this and this was much simpler than trying to get windbg to read the symbols generated by g++ or read the assembly code. Hope this helps somebody having the same issue.
References:
How to attach a process in gdb
my Qt (QML/C++) application crashes and I can not find the reason why. I tried to output a lot of information but some signal/slot connection probably causes a crash. I spent many hours trying to find the reason but I failed.
The only good point is that I can reproduce the crash whenever I want.
Unfortunately I don't know hot to use the included GDB debugger. This is the output I got:
How do I find from this what happened and where? I need to find at least the function, in which my application crashed.
Or what else could I try? Unfortunately I can not disable the signal/slot connections or the associated functions, because then I can not get to the point, where it crashes.
Qt has detailed documentation on how to install a debugger found here: QtCreator Debugger
MingW does have a GDB that can be used to debug the application better. You can also use CDB to debug, just depends on your preference.
Once that is installed, you'll be able to set breakpoints and check variable information to see where your program is crashing using the Debugger view in QtCreator.
Tools->Options->Build & Run
If you have Qt version kit like this you need to check debuggers.
https://i.stack.imgur.com/LaY1p.png
https://i.stack.imgur.com/8kTG6.png
You need to install MinGW and after install you will be have debugger. After install press F5 to start debuging.
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.
I have a big project solution that I am trying to execute, it builds perfectly fine in both release as well as debug mode. The problem is when I try to execute it the debug one is fine but release mode creates segmentation fault and creates a core dump.
Now can anyone help me about how to find out the line number in the code that might have caused the segmentation fault. I tried using gdb but couldn't do much.
Now can anyone help me about how to find out the line number in the code that might have caused the segmentation fault.
Not with the information you've provided (which is insufficient).
You should read GDB documentation. Here is a good place to start.
You should load the executable and core into GDB, and use where command to fund out which function you are crashing in.
Since the crash only happens in "release mode", you'll need to figure out how to add -g flag to your release mode build. Once you've done that, GDB will tell you the file and line number where the crash happens.
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".