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: [Select]

*thisto 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?

Also, the python script takes ages and runs in a continous loop somehow from time to time, blocking code::blocks completely.

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?

I really miss the debugging features the Qt Creator has

I don't know what qtCreator does... Can you describe it a bit more in detail?

Can't view many STL containers for some reasons when I fill them with classes though

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

I even got the python extension working so the mouse over hovering text works. But nope

So it is working but not working?

[BlueHazzard]

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?

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>)

I don't know what qtCreator does... Can you describe it a bit more in detail?

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.

[TobiasA]

Python seems to be enabled since pretty printing works following the article here:
http://wiki.codeblocks.org/index.php?title=Pretty_Printers

It just won't do on a std::vector<custom_class>.

[BlueHazzard]

Settings->Debugger...->Debugger->Default->Enable Watch Scripts

WARNING: This is a pitfall. The scripts you are enabling here are codeblocks internal squirrel scripts. They are outdated and will be removed soon (probably next release). This option has to be turned off!!!
The way to go is to use python scripts from gdb. How to enable them is listed in the wiki article you have found.

The printers for stl are here: https://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
But they should be included in TDM-GCC-BASE-PATH\share\gcc-6.4.0\python\libstdcxx

The printers for wxWidgets data types: https://github.com/wxWidgets/wxWidgets/blob/master/misc/gdb/print.py

So if you write your gdb init script this should be the paths you are using.

It just won't do on a std::vector<custom_class>.

This is a really bad error description.... At least provide a full gdb debugger log...

If I disable the watch scripts, GDB doesn't lock up but of course I don't see the elements in my class.

You should see the class elements with (codeblocks)scripts disabled. Can you give us a minimal project/ code example you struggle with?

[TobiasA]

Settings->Debugger...->Debugger->Default->Enable Watch Scripts

WARNING: This is a pitfall. The scripts you are enabling here are codeblocks internal squirrel scripts. They are outdated and will be removed soon (probably next release). This option has to be turned off!!!
The way to go is to use python scripts from gdb. How to enable them is listed in the wiki article you have found.

The printers for stl are here: https://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
But they should be included in TDM-GCC-BASE-PATH\share\gcc-6.4.0\python\libstdcxx

The printers for wxWidgets data types: https://github.com/wxWidgets/wxWidgets/blob/master/misc/gdb/print.py

So if you write your gdb init script this should be the paths you are using.

It just won't do on a std::vector<custom_class>.

This is a really bad error description.... At least provide a full gdb debugger log...

If I disable the watch scripts, GDB doesn't lock up but of course I don't see the elements in my class.

You should see the class elements with (codeblocks)scripts disabled. Can you give us a minimal project/ code example you struggle with?

I think that mentioned pitfall is my problem... Thanks for the advice, I will do so.

The bad thing is that I can't provide a gdb log since code::blocks freezes, making it impossible to copy & paste the log.
Based on what you said about the mentioned pitfall with the watch scripts, I think that this will solve the problem.

[BlueHazzard]

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.

Can you give the error output? Or a minimal code example? Or the FULL gdb log? Something to work with and possibly fix it?
Note: You can use any c++ expression in the watches. So you can also cast the this pointer to any other (valid) derived class and it will evaluate. You can also use function calls and so on...
[Edit:]WARNING: But be careful: a invalid memory access will crash your program and it is not for sure you can continue debugging also if you remove the invalid expression from the watches.
Also have a look at this: https://stackoverflow.com/a/8529137 --> https://sourceware.org/gdb/onlinedocs/gdb/Print-Settings.html
You may type the

Code: [Select]

set print object onin the gdb command line (the text entry field below the debugger log). Or add it to the init commands in the settings

[TobiasA]

EDIT: Don't read this wall of text, read my next post. The solution is so simple... Once you know it.

So I disabled the watch script. GDB says it already registered this printer, so this should be OK. The TDM GCC comes with full python support right out of the box as it seems.
Didn't add the wxwidgets printer yet, but I didn't want to bring too much complexity to my problem if STL still doesn't work right.
I also tried adding my own pp.gdb to the startup line for gdb- but the printer for STL is already registered.
The type is recognized now, but the data fields are not.
Well, the good thing is that I've never ever came so far as now. That watch script was the big pitfall, now I'm not so far away of having working. I just need to figure out how to access the elements of a vector.
Also, the "*this" hint was one big step forward.

And a really minimum example that shows it can be found in another thread:
http://forums.codeblocks.org/index.php/topic,21998.15.html
That isn't my problem though since I'm using the python-enabled TDM GCC already setup for GCC.
However, they provide a true minimum sample.

Code: [Select]

#include <iostream>
#include <vector>

using namespace std;

int main()
{
    vector<double> test;
    test.push_back( 22.44 );
    test.push_back( 1.3795933261199322e-306 );

    cout << "Hello world!" << endl;
    return 0;
}

Which gives me the output of the png attached. I had expected to read at least the size of the vector if the content cannot be parsed because it is some custom class. At least that is how other IDE's (read: GDB implementations) handle it.
The gdb output for this minimum example is:

Code: [Select]

Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: C:\Users\Adams\Documents\CodeBlocks\consoletestproject\
Adding source dir: C:\Users\Adams\Documents\CodeBlocks\consoletestproject\
Adding file: C:\Users\Adams\Documents\CodeBlocks\consoletestproject\bin\Debug\consoletestproject.exe
Changing directory to: C:/Users/Adams/Documents/CodeBlocks/consoletestproject/.
Set variable: PATH=.;C:\TDM-GCC-32\bin;C:\TDM-GCC-32;C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\Intel\iCLS Client;C:\Program Files\Intel\iCLS Client;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x86;C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x64;C:\Program Files\Intel\WiFi\bin;C:\Program Files\Common Files\Intel\WirelessCommon;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Skype\Phone;C:\Program Files\TortoiseSVN\bin

[debug]Command-line: C:\TDM-GCC-32\bin\gdb32.exe -nx -fullname -quiet  -args C:/Users/Adams/Documents/CodeBlocks/consoletestproject/bin/Debug/consoletestproject.exe
[debug]Working dir : C:\Users\Adams\Documents\CodeBlocks\consoletestproject

Starting debugger: C:\TDM-GCC-32\bin\gdb32.exe -nx -fullname -quiet  -args C:/Users/Adams/Documents/CodeBlocks/consoletestproject/bin/Debug/consoletestproject.exe
done

[debug]> set prompt >>>>>>cb_gdb:
[debug]Skip initializing the scripting!

Setting breakpoints

[debug]Reading symbols from C:/Users/Adams/Documents/CodeBlocks/consoletestproject/bin/Debug/consoletestproject.exe...done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.9.1
[debug]Copyright (C) 2015 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "mingw32".
[debug]Type "show configuration" for configuration details.
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]Find the GDB manual and other documentation resources online at:
[debug]<http://www.gnu.org/software/gdb/documentation/>.
[debug]For help, type "help".
[debug]Type "apropos word" to search for commands related to "word".
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.9.1

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> directory C:/Users/Adams/Documents/CodeBlocks/consoletestproject/
[debug]Source directories searched: C:/Users/Adams/Documents/CodeBlocks/consoletestproject;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> break "C:/Users/Adams/Documents/CodeBlocks/consoletestproject/main.cpp:15"
[debug]Breakpoint 2 at 0x40140a: file C:\Users\Adams\Documents\CodeBlocks\consoletestproject\main.cpp, line 15.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: C:\Users\Adams\Documents\CodeBlocks\consoletestproject\bin\Debug\consoletestproject.exe

Child process PID: 6408

[debug][New Thread 6408.0x1124]
[debug]Breakpoint 2, main () at C:\Users\Adams\Documents\CodeBlocks\consoletestproject\main.cpp:15
[debug]C:\Users\Adams\Documents\CodeBlocks\consoletestproject\main.cpp:15:248:beg:0x40140a
[debug]>>>>>>cb_gdb:

At C:\Users\Adams\Documents\CodeBlocks\consoletestproject\main.cpp:15

[debug]> info locals
[debug]test = {<std::_Vector_base<double, std::allocator<double> >> = {_M_impl = {<std::allocator<double>> = {<__gnu_cxx::new_allocator<double>> = {<No data fields>}, <No data fields>}, _M_start = 0x711650, _M_finish = 0x711660, _M_end_of_storage = 0x711660}}, <No data fields>}
[debug]>>>>>>cb_gdb:
[debug]> info args
[debug]No arguments.
[debug]>>>>>>cb_gdb:
[debug]> whatis foldingvector
[debug]No symbol "foldingvector" in current context.
[debug]>>>>>>cb_gdb:
[debug]> bt 30
[debug]#0  main () at C:\Users\Adams\Documents\CodeBlocks\consoletestproject\main.cpp:15
[debug]>>>>>>cb_gdb:
You should however ignore that foldingvector entry, this was still written in my watchlist.

However, what is interesting is that in the other thread, someone commanded "whatis test[0]" but this gives me the following log:

Code: [Select]

[debug]> whatis test[0]
[debug]Could not find operator[].
[debug]>>>>>>cb_gdb:

Could not find operator[].

And "output test" gives:

Code: [Select]

[debug]> output test
[debug]{<std::_Vector_base<double, std::allocator<double> >> = {_M_impl = {<std::allocator<double>> = {<__gnu_cxx::new_allocator<double>> = {<No data fields>}, <No data fields>}, _M_start = 0x711650, _M_finish = 0x711660, _M_end_of_storage = 0x711660}}, <No data fields>}>>>>>>cb_gdb:

{<std::_Vector_base<double, std::allocator<double> >> = {_M_impl = {<std::allocator<double>> = {<__gnu_cxx::new_allocator<double>> = {<No data fields>}, <No data fields>}, _M_start = 0x711650, _M_finish = 0x711660, _M_end_of_storage = 0x711660}}, <No data fields>}

I think this is the root of the problem..?
To be honest I am lost completely why this seems to work on some systems and on others, it doesn't.

[TobiasA]

No way... I followed a rather old instruction somewhere in some forum when setting up CodeBlocks. On this, all hooks in the debugger settings were checked except the last three.

..which is totally wrong...   

Sooo.... The path to get it working is quite simple:
- Use the latest TDM GCC
- Settings -> Debugger... -> GDB/CDB Debugger -> Default -> Enable watch scripts -> Set to "off"
- Settings -> Debugger... -> GDB/CDB Debugger -> Default -> Disable startup scripts (-nx) (GDB only) -> Set to "off"

So the startup scripts (read: .gdbinit) were disabled in my setup, effectively disabling the pretty printing of STL containers 

It prints literally everything! Thank you sooo much!

This solution might work for the guy from the other thread as well... Should I drop a note over there?