Valgrind produced a vgcore.NNNN file -- how do I debug the core using GDB? Do I need to use the original executable and supply the core, or is there some other way to do it?
Using valgrind as the root executable doesn't seem to work, and using the executable that was being run under valgrind directly in GDB with the core seems to produce bad backtraces.
This works fine for me:
gdb ./a.out vgcore.21650
and that's how you are supposed to use the vgcore.
If your program corrupted stack before crashing, then obviously you wouldn't get good stack traces from vgcore. You might want to expand your question with actual Valgrind report that led to the crash.
Related
I am trying to debug a Fortran Console application from Eclipse under Windows 10.
Building and running work fine, using the compiler from MSYS2.
However, starting the debugger yields:
Error in final launch sequence:
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Error creating process /c/Windows/system32/E:/till/uni/wasa/wasa_git/WASA-SED/E:/till/uni/wasa/wasa_git/WASA-SED/wasa_dbg.exe, (error 2).
The gdb.exe is found correctly, but it seems as if the path to the binary is prepended with /c/Windows/system32/ and one time too many the actual path E:/till/uni/wasa/wasa_git/WASA-SED, which obviously causes gdb to fail.
I tried using absolute, relative, and no paths to the binary in the debug configuration settings, all with the same result.
How can I fix this? Thanks in advance.
For me, the problem seems to be related to the version of gdb that I use.
I had used an instance from a recent MSYS2 distribution (i.e. GNU gdb (GDB) 11.1), which produced the error above.
Falling back on an older version (GNU gdb (GDB) 7.9.1) worked as expected.
I solved this by prepending the PATH-variable with the path to the old MSYS2 directory:
SET PATH=c:\mingw4eclipse\bin\;c:\mingw4eclipse\mingw_64\bin\;%PATH%
Putting this into batch file that then calls Eclipse ensures that no other workflows (using the newer MSYS2) are affected.
I'm newbie to emulator. Nowadays I try to view src code of mgba(GBA Emulator).
https://github.com/mgba-emu/mgba
I built and found option -g.
-g option means Start GDB session (default port 2345) from help.
Is it able to be debugged with GDB?
How can I debug with GDB?
Please tell me how to or other methods to trace source code?
(Sorry for my poor English.)
The -g option means you can remotely debug your rom with a remote debugger of gdb like gdb, ghidra or radare2. You will need another tool as mentioned before.
Sadly you can not debug remotely a classic gameboy rom. It only works for gameboy advance roms.
If you just want to debug the rom with no remote debugging access you can still use gdb from mgba with no remote debugging using the command
mgba -d your_rom.gb
a terminal should start. Then use gdb commands such as c to continue.
If you do not like gdb, you can get a look at BGB if you prefer a more graphic debugger.
I'm trying to develop code under 64-bit Cygwin, and I'm having trouble getting a core dump file that I can use under GDB. The code is compiled using GCC 7.3.0, and I've just updated my Cygwin bits. ulimit -c is unlimited.
I've got my $CYGWIN variable set to point to dumper, and that appears to be being launched on crashes. I get a pop-up, and the message
*** starting debugger for pid 5288, tid 9464
*** continuing pid 5288 from debugger call (1)
Aborted (core dumped)
and a core file (basic.exe.core) is created in the current dir.
When I try to run (the stock Cygwin) GDB on this
gdb tests/basic.exe --core=basic.exe.core
I get the normal version intro, Reading symbols..., and then a warning
warning: core file may not match specified executable file.
and GDB crashes (and dumps its own core file). The crashing program was launched from the Cygwin bash command line (as ./tests/basic.exe).
It's been a long time since I've tried to develop under Windows or Cygwin, so it's quite possible that I'm doing something stupid. Or, alternatively, it may be that GCC 7.3.0 is doing something wrong or that I configured it poorly when I built it.
Any help will be appreciated.
here is a link to a C++ (CLion) project. I've distilled/simplified the issue down as much as I could.
The problem is that when debugging, LLDB (version 3.9.0) crashes.
Steps to reproduce crash:
Open project with CLion 2017.1 (use built in LLDB for debug)
Compile the Project
Place breakpoint in main.cpp line 14
Run in debug mode.
Once you're at line 14 breakpoint, then output the variable "an_integer" via the "print an_integer" command.
Crash
The Error/Crash Report:
Assertion failed: (D->getCachedLinkage() == LV.getLinkage()), function
getLVForDecl, file
/Applications/buildAgent/work/92515a49514b3993/lldb/llvm/tools/clang/lib/AST/Decl.cpp,
line 1360.
Note that this crash occurs with LLDB v3.9.0 on Mac v10.12.4. But it does not occur with LLDB 3.7.0 on Mac 10.12.4.
Ultimately, I'm wanting to know if I'm doing something dumb in my project code? If not, is this a bug with CLion or LLDB? Is there somewhere that I should post this to help get the bug (if it is that) resolved?
That doesn't look like your bug. For some reason lldb is having trouble ingesting the type information produced by the compiler.
I don't have clion so I can't try that, but if I just build your test project, either with a PCH or without, using clang from Xcode 8.3 I don't see this crash. Best thing to do is to build this project with CLion, then make a dSYM (if CLion doesn't do this for you.) You do that by running:
> dsymutil TestingLLDBBreaking
Check that you can reproduce the crash with the dSYM, and if so then file a bug with http://bugreporter.apple.com with the executable and the .dSYM.
So I had the same problem for a while.
just before almost formatting my mac I've re-cloned the project to a different directory and ran it from there. No issues. (i'm sure its a mac-os thing).
Good luck :)
I've recently updated my system to Ubuntu 14.04 LTE. I've also updated the version of my QtCreator to 3.3.
When I run in Release mode, no problem. However, when I tried to debug, something strange happens: The system throws a Segmentation Fault, and the application give me this message:
&"warning: GDB: Failed to set controlling terminal: Inappropriate ioctl for device\n"
I saw other comments that propose to downgrade the GDB version from 7.8 to 7.7 and other saying the opposite thing. I tried both but nothing works.
I saw some posts saying that it's a bug, but I'm not being able to find any solution in these messages.
Have anyone some suggestions?
Thank you very much!
EDIT:
I tried to use gdb via command line, and it works a little bit different: The segmentation fault remains, but the error is different:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff1da2a70 in boost::math::lanczos::lanczos_initializer<boost::math::lanczos::lanczos17m64, long double>::init::init() ()
from /usr/lib/libpcl_sample_consensus.so.1.7
I removed the flag -std=c++0x from my makefile in order to not use c++11. Then, using command line gdb, the debugging works. However, using QtCreator it still not working.
Any idea? Thaaanks!
I get this message every time I debug, but the debugging works fine. I'm sure I found a comment on the QT forums that says just ignore it.
Have you tried debugging a trivial "hello world" program?