User forums > Using Code::Blocks
Debugging with TDM GCC 32bit + CodeBlocks- can't find member variables
TobiasA:
Hello everyone,
I have a question about debugging with TDM GCC together with Code::Blocks. I have used the Qt toolchain before, and I could view all members of class members by browsing though "this".
I have made multiple attempts, but I can't work out to get this done in Code::Blocks with TDM GCC 5.1. Currently I am working on some wxWidgets projects and I really miss the debugging features the Qt Creator has. I don't think this is related to Code::Blocks, but maybe someone of you has an idea.
I'm on CodeBlocks 16.01 (although I tried the nightly builds as well) with TDM GCC (latest release, GCC 5.1) 32bit, Windows 7 (have tried 3 computers with Windows 7). I use the GDB32.exe coming with TDM GCC.
Debugging works with local variables and breakpoints and stuff. Can't view many STL containers for some reasons when I fill them with classes though...
What I never see are the class members. They are just invisible to me. I even got the python extension working so the mouse over hovering text works. But nope. I'm even thinking about using the Qt Creator suite for plain C++ with WxWidgets (that sounds weird, I know). Netbeans wasn't that bad either, however CodeBlocks works so great with WxWidgets and it's all you need for a C++ IDE, working like a charm.
And Code::Blocks isn't responsible for providing debugging symbols... So switching the project to another IDE will most likely not solve my issues...
Is there anything I can do to watch class members and STL containers? If not, can someone point me to some more recent free C++ compiler for windows which has a better debugging support? I'd like to use the same compiler for windows and linux, so the microsoft tools aren't that much of an alternative.
Is MinGW64 better? Is the 64bit Version of TDM better?
Thank you very much!
TobiasA:
I have been searching for weeks... It seems that the Qt creator is looking for all members of "this", while the standard GDB doesn't, but supports it when you add them by yourself...
However, it seems you need to have python enabled and use the debugger from the gdb32/bin/gdb32.exe - there is a second one in the main\bin dir which didn't bring me that much of a success somehow.
Also, the python script takes ages and runs in a continous loop somehow from time to time, blocking code::blocks completely.
When parsing a vector of classes, it evaluates all the elements (I can see that in the debugger log) and then enters a loop until eternity... Any ideas?
Thanks a lot!
BlueHazzard:
What are you exactly doing?
Do you add
--- Code: ---*this
--- End code ---
to the watches window? This works fine for me. Without problems
What "does not work" mean? Does it display an error? Are you using the hover feature or are you adding the members to the watches window?
Is the problem that codeblocks can not interpret the debugger output? Does it show fine in the debugger log?
--- Quote ---Also, the python script takes ages and runs in a continous loop somehow from time to time, blocking code::blocks completely.
--- End quote ---
This should not be the case... Or does your vector has 1000000000 elements? Then inspecting them in the debugger is always a bad idea... What scripts are you using?
--- Quote ---I really miss the debugging features the Qt Creator has
--- End quote ---
I don't know what qtCreator does... Can you describe it a bit more in detail?
--- Quote ---Can't view many STL containers for some reasons when I fill them with classes though
--- End quote ---
You need the python scripting with the right scripts. I don't know if there are suitable scripts out there. I would look at the gcc site for them
--- Quote --- I even got the python extension working so the mouse over hovering text works. But nope
--- End quote ---
So it is working but not working? ???
BlueHazzard:
--- Quote from: TobiasA on December 20, 2017, 03:45:04 pm ---When parsing a vector of classes, it evaluates all the elements (I can see that in the debugger log) and then enters a loop until eternity... Any ideas?
--- End quote ---
You should limit the range of the elements and turn off the full debugger logging. The logging slows down the process considerably. There is a big limitation on the text interface codeblocks is using to communicate with gdb that slows down the whole process a lot. But you can make it better with the right python script and not display a ton elements. Limit the element count in the properties of the watch (right click->Properties)
TobiasA:
I think I'm a bit lost... First of all, thanks for the fast reply.
Actually, with what I found out is that I'm not even sure if I have a python enabled GDB or not. If I disable the watch scripts, GDB doesn't lock up but of course I don't see the elements in my class.
So, locking up only happens when I enable the scripts under Settings->Debugger...->Debugger->Default->Enable Watch Scripts and only when watching a vector of custom classes (nothing fancy, basically an extended struct, having about a dozen strings or so). The vector itself isn't large and in general, it is <200 entries.
To sum it up, I got the following things working:
- debug local variables that are C++ native formats (int, bool, also string is working, std::vector of int works too)
- set and enable breakpoints, step instructions, switch frames...
- with my latest discovery, I can watch class members
What still does not work:
- The GDB watch script locks up in some cases (std::vector<custom_class>)
--- Quote ---I don't know what qtCreator does... Can you describe it a bit more in detail?
--- End quote ---
Qt Creator basically adds *this to the watches list. I tried it now, but I'm in a derived class (standard wxWidgets template) from GUIFrame:: and this fails halfway (parsing GDB output failed for "*this"), giving me only one member variable and the base class GUIFrame:: with all its members.
This is exactly what I am looking for, thanks for the hint!
I can live with adding my member variables one by one since I have a lot of them... But still, even when adding a small vector that includes classes (that contains other vectors btw) my CPU 1 locks at 100% for 15 solid minutes now (until I kill the task). It's not that much- a couple of strings, a few mostly empty vectors of int... Talking about a few kb of data here if any. When using the full debug log, I can see it parsing the last element (18 or 128 in my two test files) and after the last element, it just locks CPU 1 at 100% and that's it.
If I could solve exactly this issue, I'd be happy.
I tried turning off the full debug log now, but it didn't change a thing.
Navigation
[0] Message Index
[#] Next page
Go to full version