This is my first post, so feel free to direct me elsewhere if this is in the wrong place. I'm totally new to code::blocks, and I followed the directions (twice) from here to set it up with minGW. Other than some expected warnings, it builds just fine. However, when I go to debug it, I get the following messages:
Setting breakpoints Debugger name and version: GNU gdb (GDB) 7.4
Child process PID: 3928 [Inferior 1 (process 3928) exited with code
[037777777777] Debugger finished with status 0
When I set a breakpoint, I get the following:
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.4
Child process PID: 3092
Error in re-setting breakpoint 2: Function "C:/Users/Me/Documents/My Code/MyProgram/MyProgram/main.cpp:5" not defined.
[Inferior 1 (process 3092) exited with code 037777777777]
Debugger finished with status 0
I have searched and searched, but I haven't found anything. The only relevant posts on this site,
CodeBlocks Breakpoints Ignoring Scope
codeblocks debugging
How to debug in Codeblocks?,
have not helped me at all. I've reinstalled everything twice and I have no idea what else to do to get this debugger working. Any help at all would be appreciated.
EDIT: I made "Hello World!" and it ran, but still could not be debugged. No idea what the problem is, especially since it detects gdb.
This error occurs if there is a space in your build path (in your case "My Code").
Just rename that directory or move the project to a place where there are no spaces in your path.
Reason:
Ref this link: http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks#Path_with_spaces
You may have to clean and build your project again
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 finally managed to run GDB 8.2 on macOS. But now when I'm trying to debug something, I got the following:
(gdb) b main
Breakpoint 1 at 0x100001e94: file project/src/main.cpp, line 34.
(gdb) run
Starting program: project/cmake-build-debug/program
[New Thread 0x1203 of process 5140]
[New Thread 0xf03 of process 5140]
[5]+ Stopped sudo gdb beast
I also tried using it inside CLion. In that case, GDB freezes indefinitely with this:
For help, type "help".
Type "apropos word" to search for commands related to "word".
Function "__cxx_global_var_init" not defined.
Function "__libc_csu_init" not defined.
[New Thread 0x1003 of process 4186]
[New Thread 0xf03 of process 4186]
Warning:
Cannot insert breakpoint -1.
Cannot access memory at address 0xf7ce
Does anybody know what's going on?
[5]+ Stopped sudo gdb beast
This is a gdb bug. The typical cause of this is gdb trying to write something to stdout after it has already given the terminal to the inferior. I'm not sure whether this instance has been fixed, probably because this is most likely only showing up due to:
Warning:
Cannot insert breakpoint -1.
Cannot access memory at address 0xf7ce
... this. This is another bug in gdb, namely that it wasn't updated to account for dyld changes in High Sierra. This bug is fixed and will be in gdb 8.3 (or in any rate in the release after 8.2.1, regardless of what number it is finally given).
Building a gdb from git master will work fine.
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?