i am debugging c++ with eclipse on a linux VM.
The eclipse I am using is Kepler Service Release 1.
I compile the files using Automake.
When I try to debug in Eclipse and do stepover it sometimes jump to backward lines, sometimes it goes into the line. Also when there is a problem it just shows nothing. When I try to see variables it doesn't always succeed. It seems the Eclipse behavior is not so good.
I come from Windows programming and it looks very much like I saw when we compiled release version and tried to debug it in Visual.
Can anyone plesae assist? I can't debug like this. Is there any configuration? something I do wrong?
Thanks
As Martin James stated all I needed was to turn off all optimizations.
I had -o2 flag and needed to remove it.
Related
After the setup I've done in the properties of the project: at C++Compiler and Linker in both Release and Debug configurations I tried to build the project, which went successful.
Then I decided to run it and had some difficulties: using External Terminal, that did absolutely nothing, Standard output, that showed some text related to dll files I've clue about, Internal Terminal, that showed the very same text.
After that didn't work I went for cmd execution and what I saw was this.
Could you explain what that means and what I'm supposed to do. I'm new to all that kind of stuff, so I apologise if I did something stupid.
Cheers
EDIT: If not seen, I'm using Windows 10 and the version of SFML is GCC 7.3.0 MinGW (DW2) - 32-bit
I'm making a wxWidget application for windows. I'm working with code:blocks 13.12 and MinGW 4.8 in windows 7.
I enable the -pg option in settings->compiler and after compiling try to open the plugins->code profiler and the result is this:
gprof:
file`C:\Users\josele\Documents\C_C++\DLL\SQLManager\bin\Release\SQLManager.exe'
has no symbols
Basicly I don't know how profiling works in code:block and also my general knowledge of profiling is quite reduced.
I'm looking for solve this or a tutorial of: how profiling works in code:blocks?.
If you need more information, only let me know. Thank you in advance.
PD. I also run the .exe before calling the plugins->code profiler with a positive exit of the program
I just solve that problem with this posts:
http://forums.codeblocks.org/index.php?topic=12237.0
http://forums.codeblocks.org/index.php?topic=14798.0
I went to Project->build options and there I turn off optimizations and enable the pofiler.
What solved it for me was turning off the "-s" compiler flag, which seems to be on by default in CB release flags.
So, I have no idea why, but breakpoints in my code::blocks project are no longer working. I'm using MinGW-W64 compiler and GDB. I used to be able to use breakpoints, but now, for some reason, when I add them to my code they do absolutely nothing - code execution goes right past them without stopping.
Why might this be happening?
You might be compiling your code in release mode. Try changing it to debug mode. Checkout http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks on how to turn on debugging symbols.
Yesterday I had done a lot of things like updating GCC, Clang and reinstalling Qt Creator.Today when debugging my code step by step, the debugger was showing the disassembley rather than the C++ code I wrote. Pressing F10 or F11, the debugger was moving into assembly code not the .cpp nor .h files I wrote. F11 can only go into the library files but never into the files I wrote.
The arrow appeared in disassembler:
Rather than in main.cpp:
How can I configure Qt Creator such that the debugging arrow tracks each line in the C++ code?
For others who also had this problem but none of the solutions above worked (like me), I found out that the issue for me was simply happening because my project was inside of a directory with special characters (/home/fabio/criação/project) the criação folder seems to have caused the problem. After I changed to /home/fabio/Desktop/project it stop happening.
I ran into a very similar problem debugging code built with the clang toolset in qtcreator, and this answer fixed me up:
gdb doesn't find source files compiled by clang++
You can quickly check if that solution will work for you by navigating to the root of your solution in a shell window and then invoking qtcreator from there...set a break point in main() and try debugging - if it stops and shows source in main.cpp, it's quite likely this is the problem.
If that does work for you, there are probably several better ways to implement the permanent solution suggested by https://stackoverflow.com/users/1632219/rene, but the method that worked for me was to modify my qmake mkspec file for the clang toolset. On my system, it lives in /usr/local/Trolltech/Qt-4.8.5/mkspecs/common/clang.conf, so all I had to do was put a clang invoker script with 'clang++ "$#"' in ~/bin/clang-compile and then set QMAKE_CXX in the mkspec to clang-compile. With that change, when the clang toolset is selected, qmake builds make files that use clang-compile instead of clang++ and then debugging works everywhere.
At last, I found that it was Clang that had caused this problem. After changed the kit back to using gcc, it just worked fine. But not sure whether it's Clang's fault or that the script Qt produced for compiling has any problem. Anyway just put the answer here in case anyone else who might encounter the same situation.
Goto "Help->About Plugins" and check the "ClangCodeModel" and restart QT.
There is a bug in version Qt 5.6.1 (MSVC 2013, 32 bit) QT Creator4.0.3.
In debug mode put your breakpoint. Then hit the step into(F11) it will start debugging now. To go to your code hit the step-over(F10) until you come to the code page.
I have searched about this problem but nothing worked. Some solution, i didn't get.
This is very annoying issue.
Maybe it will work if you clean, qmake and rebuild.I solved this problem by using this method.
I’m porting a C++ sdk from Windows to Mac OSX 10.5. I have a problem in Xcode where my breakpoints in certain files will only be hit if I set them while debugging. If I stop debugging and then restart, the breakpoints no longer get hit. If I add them while not debugging, they don't get hit. This is only in certain files and my breakpoints are always dark blue. i.e. I can’t tell the difference between a breakpoint that will get hit and one that won’t.
Specifically, my sdk is made up of various dynamic libraries. These are built using Perforce jam, which calls the various compile and link executables depending on my OS and compiler version (such as Visual Studio’s cl.exe and link.exe). I have a simple (unit testing) command line application that links to these dynamic libraries and calls code in them. This application on Windows is a Visual Studio project, in which I set breakpoints on library code and expect them to be hit.
I’ve created the same C++ command line utility application in Xcode 3.1.2 that links to the sdk dylibs and calls code in them. Some of the breakpoints work fine. I can set breakpoints in code that’s called from the troublesome code, and step out to the troublesome code, which I can then step through fine. The troublesome code is compiled into the same dylib as code that works fine. It’s also long and complicated enough not to be a candidate for inlining.
I’ve tried the following:
Turn Load symbols lazily off.
Compile with both gcc 4.0 and gcc 4.2.
Do a full clean and shutdown.
Delete the user-specific files of the xcodeproj package.
Rename the files so they can’t clash with system files.
Clear everything out of the Breakpoints window.
Create a new Xcode project.
My application is compiled in debug with DWARF format and my libraries are built with the –g flag (along with –v, –arch i386 and –fvisibility-inlines-hidden).
Help would be much appreciated. Thanks.
Update: sorry for not updating this, my Mac port project was postponed. I never resolved this, but discovered that it actually only occurs in constructor bodies. I'll revisit this as and when I hit the problem again.
Have you tried these?
Why aren't my breakpoints working?
Not really an answer: You should make a bug report in the official Apple bugtracker. The chances are high that you get an answer sooner or later there - or perhaps it is really a bug.