Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: nji on June 22, 2017, 09:31:46 am

Title: Showing vector elements in debugger
Post by: nji on June 22, 2017, 09:31:46 am

I'm using codeblocks in its actual release (16.01) with tdm mingw 4.9.2 @ Win7Prof64.
When debugging I need to see the contents of a std::vector<double>.
For example: myVector [2].
No matter if I add myVector to the watches ... or then "properties" ("watch as array"),
or if I watch myVector [2] directly ... no success in showing the value,
only quite useless internal information.
Of course I found some threads about that in the forum, but all seem quite old,
some quite arrogant, pointing to nowhere, and very confusing for a newbie like me.
Looks like codeblock is not able to show the info from gdb (Although vector etc.
are c++ standard since years!)
And therefore a python script is needed. And for that python has to be "activated"
while building gdb itself (which is not the case for the windows binaries).
While the latter one seems refused by mingw developers because python project
doesn't cooperate. A cul-de-sac.
And even if all this would work, one would have to do further
steps to build and include gdb-command scripts etc.
If I get it right.
CAN THIS BE POSSIBLE?
Or is it a joke?
In the year 2017 you have to printf to debug a c++ standard element, when using
codeblock/ gcc?
It would be nice if someone could lighten the matter up.
Are there simple steps ... for all the ones who want to change from M$.
Or will the next release of codeblocks do it all by itself?
The situation as it presents now (and not only this example) is quite deterrent.
Which is a pity.
Thank you for hints.

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 22, 2017, 11:25:51 am

What i have done and it seems to work:
1) Use a python enabled gdb. I don't know but i think the tdm gcc has python enabled
2) In Settings->Debugger->GDB/CDB debugger->Default->Debugger initilization commands:
 

Code

python
import sys
sys.path.insert(0, 'PATH_TO_TDM\share\gcc-4.9.2\python')
from libstdcxx.v6.printers import register_libstdcxx_printers
end

3) make sure you have deactivated "Enable watch scripts"

If you have trouble:
Activate full debugger logging: In Settings->Debugger->GDB/CDB debugger->Common->Full (Debug) log
and post the log here inside code tags (the # symbol in the new post editor)

Quote

CAN THIS BE POSSIBLE?
Or is it a joke?
In the year 2017 you have to printf to debug a c++ standard element, when using
codeblock/ gcc?

See it as learning.. If you know the things behind all this you will get a better programmer

Quote

Or will the next release of codeblocks do it all by itself?

Don't know... The team abandoned the internal scripting and decided to use the gdb internal python scripting. If you use a compiler that has no python support cb could not do anything about this... In general this are gdb problems and not really codeblocks problems ;)

Title: Re: Showing vector elements in debugger
Post by: nji on June 22, 2017, 11:48:45 am

Quote from: BlueHazzard on June 22, 2017, 11:25:51 am

What i have done and it seems to work:
1) Use a python enabled gdb. I don't know but i think the tdm gcc has python enabled

No unfortunately NOT.
If I do the test from http://wiki.codeblocks.org/index.php?title=Pretty_Printers (http://wiki.codeblocks.org/index.php?title=Pretty_Printers)
my gdb says that python scripting is deactivated.
And if I search deeper for a python activated gdb I get lost. More and more problems arise.
(Install special versions of mingw etc.)
As I said already - a cul de sac this way.

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 22, 2017, 01:01:41 pm

From this side, it tells me that tdm gcc has python enabled gdb

http://tdm-gcc.tdragon.net/index.php/

This should be the download link
http://sourceforge.net/projects/tdm-gcc/files/GDB/gdb32-7.9.1-tdm-1.zip/download
it should be possible to simply copy this version over your installed version..

Title: Re: Showing vector elements in debugger
Post by: nji on June 22, 2017, 01:28:03 pm

In the actual codeblock package (v. 16.01) there is gdb v. 7.6.1, and there python is NOT enabled.
Due to your hint to the tdm site, (up from?) v. 7.9.1. python is enabled.

OK ... I copied the new version of gdb over the installed version und entered the new name gdb(server)32.exe instead of gdb(server).exe into cb's setting. Then startet the db and added "diffVector [2]" to the watch window. The output:
(__gnu_cxx::__alloc_traits<std::allocator<double> >::value_type &) @0x147f660: <error reading variable>

diffVector shows same as before.

Code

Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target: 
Debug
Adding source dir: D:\Guido\develop\TestMovieIn\
Adding source dir: D:\Guido\develop\TestMovieIn\
Adding file: D:\Guido\develop\TestMovieIn\bin\Debug\TestMovieIn.exe
Changing directory to: D:/Guido/develop/TestMovieIn/.
Set variable: PATH=.;D:\Guido\develop\opencv\build_codeblocks\install\x86\mingw\lib;C:\Program Files (x86)\CodeBlocks\MinGW\bin;C:\Program Files (x86)\CodeBlocks\MinGW;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\Windows Live\Shared

[debug]Command-line: C:\Program Files (x86)\CodeBlocks\MinGW\bin\gdb32.exe -nx -fullname -quiet  -args D:/Guido/develop/TestMovieIn/bin/Debug/TestMovieIn.exe
[debug]Working dir : D:\Guido\develop\TestMovieIn

Starting debugger: C:\Program Files (x86)\CodeBlocks\MinGW\bin\gdb32.exe -nx -fullname -quiet  -args D:/Guido/develop/TestMovieIn/bin/Debug/TestMovieIn.exe
done

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

Setting breakpoints

[debug]Reading symbols from D:/Guido/develop/TestMovieIn/bin/Debug/TestMovieIn.exe...
[debug]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]> python
import sys
sys.path.insert(0, 'C:\Program Files (x86)\CodeBlocks\MinGW\share\gcc-4.9.2\python')
from libstdcxx.v6.printers import register_libstdcxx_printers
end
[debug]>>>>>>>>>>cb_gdb:
[debug]> directory D:/Guido/develop/TestMovieIn/
[debug]Source directories searched: D:/Guido/develop/TestMovieIn;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> break "D:/Guido/develop/TestMovieIn/main.cpp:38"
[debug]Breakpoint 2 at 0x401579: file D:\Guido\develop\TestMovieIn\main.cpp, line 38.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: D:\Guido\develop\TestMovieIn\bin\Debug\TestMovieIn.exe 

Child process PID: 4544

[debug][New Thread 4544.0x114c]
[debug][New Thread 4544.0x13dc]
[debug][Switching to Thread 4544.0x13dc]
[debug]Breakpoint 2, ComputePart (source=..., diffVector=..., nLap=@0x55f2ce: 20, nThreads=@0x4d1fe48: 1, nThreadNo=@0x55f2c8: 0) at D:\Guido\develop\TestMovieIn\main.cpp:38
[debug]D:\Guido\develop\TestMovieIn\main.cpp:38:1231:beg:0x401579
[debug]>>>>>>cb_gdb:

At D:\Guido\develop\TestMovieIn\main.cpp:38

[debug]> info locals
[debug]capt = <incomplete type>
[debug]refS = {width = 1280, height = 720}
[debug]frame = {flags = 1124007936, dims = 0, rows = 0, cols = 0, data = 0x0, datastart = 0x0, dataend = 0x0, datalimit = 0x0, allocator = 0x0, u = 0x0, size = {p = 0x4d1fcb0}, step = {p = 0x4d1fcd8, buf = {0, 0}}}
[debug]s = {<cv::Vec<double, 4>> = {<cv::Matx<double, 4, 1>> = {val = {0, 0, 0, 0}}, <No data fields>}, <No data fields>}
[debug]frameRes = {flags = 1124007936, dims = 0, rows = 0, cols = 0, data = 0x0, datastart = 0x0, dataend = 0x0, datalimit = 0x0, allocator = 0x0, u = 0x0, size = {p = 0x4d1fce8}, step = {p = 0x4d1fd10, buf = {0, 0}}}
[debug]frameDuo = {_M_elems = {{flags = 1124007936, dims = 0, rows = 0, cols = 0, data = 0x0, datastart = 0x0, dataend = 0x0, datalimit = 0x0, allocator = 0x0, u = 0x0, size = {p = 0x4d1fd20}, step = {p = 0x4d1fd48, buf = {0, 0}}}, {flags = 1124007936, dims = 0, rows = 0, cols = 0, data = 0x0, datastart = 0x0, dataend = 0x0, datalimit = 0x0, allocator = 0x0, u = 0x0, size = {p = 0x4d1fd58}, step = {p = 0x4d1fd80, buf = {0, 0}}}}}
[debug]frameNum = 0
[debug]>>>>>>cb_gdb:
[debug]> info args
[debug]source = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x55f27c "26229.wmv"}}
[debug]diffVector = @0x28fecc: {<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 = 0x1c19678, _M_finish = 0x1c19678, _M_end_of_storage = 0x1c80850}}, <No data fields>}
[debug]nLap = @0x55f2ce: 20
[debug]nThreads = @0x4d1fe48: 1
[debug]nThreadNo = @0x55f2c8: 0
[debug]>>>>>>cb_gdb:
[debug]> whatis diffVector
[debug]type = std::vector<double, std::allocator<double> > &
[debug]>>>>>>cb_gdb:
[debug]> output diffVector
[debug](std::vector<double, std::allocator<double> > &) @0x28fecc: {<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 = 0x1c19678, _M_finish = 0x1c19678, _M_end_of_storage = 0x1c80850}}, <No data fields>}>>>>>>cb_gdb:
[debug]> whatis diffVector [2]
[debug]type = std::vector<double, std::allocator<double> >::reference
[debug]>>>>>>cb_gdb:
[debug]> output diffVector [2]
[debug](__gnu_cxx::__alloc_traits<std::allocator<double> >::value_type &) @0x147f660: 1.3795933261199322e-306>>>>>>cb_gdb:

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 22, 2017, 04:11:41 pm

If you look in the log:

Code

s = {<cv::Vec<double, 4>> = {<cv::Matx<double, 4, 1>> = {val = {0, 0, 0, 0}}, <No data fields>}, <No data fields>}

there seems that the matrix is deducted right, so the printing seems to work..


and there seems to be the right value:

Code

 whatis diffVector
[debug]type = std::vector<double, std::allocator<double> > &
[debug]>>>>>>cb_gdb:
[debug]> output diffVector
[debug](std::vector<double, std::allocator<double> > &) @0x28fecc: {<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 = 0x1c19678, _M_finish = 0x1c19678, _M_end_of_storage = 0x1c80850}}, <No data fields>}>>>>>>cb_gdb:

so you still get some different output from the script.
Probably you have to update the python script:
https://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python/libstdcxx/v6/

this is what i get with this test code:

Code

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

Code

[debug]> whatis test
[debug]type = std::vector<double>
[debug]>>>>>>cb_gdb:
[debug]> output test
[debug]std::vector of length 2, capacity 2 = {22.440000000000001, 1.3795933261199322e-306}>>>>>>cb_gdb:

Title: Re: Showing vector elements in debugger
Post by: nji on June 22, 2017, 06:26:27 pm

Could you please try what happens when you add

Code

 test [1]

to the watch?

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 22, 2017, 07:03:17 pm

Code

[debug]> whatis test[1]
[debug]type = double
[debug]>>>>>>cb_gdb:
[debug]> output test[1]
[debug]1.3795933261199322e-306>>>>>>cb_gdb:

i hope you don't use the space in the watch window, like here in the code section

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 22, 2017, 07:05:21 pm

jep, you are using a space... this is wrong. Don't use a space in the watch name and you should be fine

Code

[debug]> whatis diffVector [2]
[debug]type = std::vector<double, std::allocator<double> >::reference

Code

whatis diffVector

is as gdb says a reference...

Title: Re: Showing vector elements in debugger
Post by: nji on June 22, 2017, 07:38:34 pm

Space or not space ... this is ... NOT ... the question  ;)

What I mean:
It doesn't matter if I add "test[1]" to the watch window (in c:b) or "test [1]" ... both don't work.
Could you please check at you?

Code

[debug]> whatis test[1]
[debug]type = std::vector<double, std::allocator<double> >::reference
[debug]>>>>>>cb_gdb:
[debug]> output test[1]
[debug](__gnu_cxx::__alloc_traits<std::allocator<double> >::value_type &) @0x19de910: <error reading variable>>>>>>>cb_gdb:

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 22, 2017, 08:05:09 pm

how does your code looks?
have you updated the scripts?

[edit:] you are right, the space makes no difference...

have you tested my simple example code from the top?

Title: Re: Showing vector elements in debugger
Post by: nji on June 22, 2017, 08:27:15 pm

It's exactly your code snipplet from above.
I updated the scripts.
test is shown correctly in debugger and in watches, while test[1] is not:

Code

[debug]> whatis test[1]
[debug]type = std::vector<double, std::allocator<double> >::reference
[debug]>>>>>>cb_gdb:
[debug]> output test[1]
[debug](__gnu_cxx::__alloc_traits<std::allocator<double> >::value_type &) @0x19de910: <error reading variable>>>>>>>cb_gdb:
[debug]> whatis test
[debug]type = std::vector<double>
[debug]>>>>>>cb_gdb:
[debug]> output test
[debug]std::vector of length 2, capacity 2 = {22.440000000000001, 1.3795933261199322e-306}>>>>>>cb_gdb:

Title: Re: Showing vector elements in debugger
Post by: oBFusCATed on June 22, 2017, 08:33:02 pm

The problem is in gdb (or the pretty printers). It tells you that it cannot read the value of this expression.

Title: Re: Showing vector elements in debugger
Post by: nji on June 22, 2017, 08:40:33 pm

How can this be?
I downloaded the newest gdb (from link above) and scripts.
And "test[1]" is not a too complex expression ... an error in gdb/ scripts should have shown before.
What about python?

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 22, 2017, 08:46:25 pm

if this matters, i have this gdb version: GNU gdb (GDB) 7.10.50.20160130-git
probably i got it from here: http://forums.codeblocks.org/index.php/topic,11301.0.html

Title: Re: Showing vector elements in debugger
Post by: oBFusCATed on June 22, 2017, 09:20:32 pm

Quote from: nji on June 22, 2017, 08:40:33 pm

And "test[1]" is not a too complex expression ...

Why do you think this is not a complex expression?
Are you sure you're python scripts match the version of you c++ standard library you're using?

Title: Re: Showing vector elements in debugger
Post by: nji on June 22, 2017, 11:34:08 pm

No, I'm not sure at all if anything matches together. I just downloaded the "updates" as pointed to in http://forums.codeblocks.org/index.php/topic,21998.msg149716.html#msg149716 (http://forums.codeblocks.org/index.php/topic,21998.msg149716.html#msg149716).
Sigh ... do you need any more explanation why M$'s comm. ed. is so popular?
Do you want my opinion about a development chain where nothing fits together, and debugging vector[1] is impossible?
...
OK, if the python scripts have to match the c++ standard library ... I moved the original scripts (from mingw 4.9.2) back.
Effect: same effect.
Does gdb has to match too?
This becomes ridiculous and frustrating.

Title: Re: Showing vector elements in debugger
Post by: oBFusCATed on June 23, 2017, 12:04:21 am

Quote from: nji on June 22, 2017, 11:34:08 pm

M$'s comm. ed.

Are you talking about visual studio?

Quote from: nji on June 22, 2017, 11:34:08 pm

Do you want my opinion about a development chain where nothing fits together, and debugging vector[1] is impossible?

This won't change anything. Patches improve the situation. Ranting is just ranting.

Quote from: nji on June 22, 2017, 11:34:08 pm

OK, if the python scripts have to match the c++ standard library ... I moved the original scripts (from mingw 4.9.2) back.
Effect: same effect.

Yes, they need to match, because the standard library changes its internals and the python script need to know the internals of the library.

Quote from: nji on June 22, 2017, 11:34:08 pm

Does gdb has to match too?

Only to the point that the Python APIs used in the scripts are compatible. But I think the gdb's python apis are relatively stable.

@bluehazzard: Does this example work for you?

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 23, 2017, 01:11:43 am

ok, here is my full working setup:
gcc: TDM-gcc 4.9.2
gdb: http://sourceforge.net/projects/gdbmingw/files/gdb2016-01-30.zip/download

from ollydbg in http://forums.codeblocks.org/index.php/topic,11301.0.html

Quote

You must install Python 2.7.5 release 32bit version on your system, as my build was linked to this python release.

you need to install python 2.7.5: https://www.python.org/download/releases/2.7.5/

stl script in TDM-GCC-32\share\gcc-4.9.2\python\libstdcxx\v6 printers.py and xmethods.py are attached. I don't remember where i got them from (probably the svn tree)

i use a gdb file in TDM-GCC-32\bin\stl.gdb :

Code

python
import sys
sys.path.insert(0, 'TDM-GCC-32\share\gcc-4.9.2\python')
from libstdcxx.v6.printers import register_libstdcxx_printers
#register_libstdcxx_printers (None)
end

and in the debugger settings:
Settings->Debugger->GDB->Default->initialization commands:

Code

source TDM-GCC-32\bin\stl.gdb

if i debug this code:

Code

#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;
}

i get this debugger log, and all works fine:

Code

Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target: 
Debug
Adding source dir: ****\
Adding source dir: ****\
Adding file: ****\bin\Debug\rerreer.exe
Changing directory to: ****.
Set variable: PATH=#######

[debug]Command-line: TDM-GCC-32\bin\gdb.exe -fullname -quiet -nx -args ****bin/Debug/rerreer.exe
[debug]Working dir : ****

Starting debugger: TDM-GCC-32\bin\gdb.exe -fullname -quiet -nx -args ****bin/Debug/rerreer.exe
done

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

Setting breakpoints

[debug]Reading symbols from ****bin/Debug/rerreer.exe...done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.10.50.20160130-git
[debug]Copyright (C) 2016 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.10.50.20160130-git

[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 200
[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]> source TDM-GCC-32\bin\stl.gdb
[debug]> directory ****
[debug]>>>>>>cb_gdb:
[debug]> break "****main.cpp:12"
[debug]Source directories searched: ****/rerreer;$cdir;$cwd
[debug]>>>>>>cb_gdb:Breakpoint 2 at 0x4013ce: file ****\main.cpp, line 12.

Source directories searched: ****/rerreer;$cdir;$cwd

[debug]> run
[debug]>>>>>>cb_gdb:Starting program: ****\bin\Debug\rerreer.exe 
[debug]> info frame

Child process PID: 7276

[debug][New Thread 7276.0x16ec]
[debug]Breakpoint 2, main () at ****\main.cpp:12
[debug]****\main.cpp:12:187:beg:0x4013ce
[debug]>>>>>>cb_gdb:Stack level 0, frame at 0x28ff30:

At ****\main.cpp:12

[debug]> whatis test
[debug] eip = 0x4013ce in main (****\main.cpp:12); saved eip = 0x4010fd
[debug] source language c++.
[debug] Arglist at 0x28ff18, args: 
[debug] Locals at 0x28ff18, Previous frame's sp is 0x28ff30
[debug] Saved registers:
[debug]  ebx at 0x28ff0c, ebp at 0x28ff18, esi at 0x28ff10, edi at 0x28ff14, eip at 0x28ff2c
[debug]>>>>>>cb_gdb:type = std::vector<double>
[debug]> output test
[debug]>>>>>>cb_gdb:
[debug]> whatis test[2]
[debug]std::vector of length 2, capacity 2 = {22.440000000000001, 1.3795933261199322e-306}>>>>>>cb_gdb:type = double
[debug]> output test[2]
[debug]>>>>>>cb_gdb:
[debug]> whatis test[0]
[debug]-2.5301706769843864e-098>>>>>>cb_gdb:type = double
[debug]> output test[0]
[debug]>>>>>>cb_gdb:
[debug]> whatis test[1]
[debug]22.440000000000001>>>>>>cb_gdb:type = double
[debug]> output test[1]
[debug]>>>>>>cb_gdb:
[debug]> bt 30
[debug]1.3795933261199322e-306>>>>>>cb_gdb:#0  main () at ****\main.cpp:12
[debug]>>>>>>cb_gdb:

i know this is all frustrating, and as soon as we will find out what goes wrong i will try to create a wiki entry with the exact steps...

[Edit:] NOTE: i have altered all paths, so you have to use absolute paths for all path entries. I also don't use any white spaces or non ASCII characters in my paths

[Edit:] add python download link

Title: Re: Showing vector elements in debugger
Post by: ollydbg on June 23, 2017, 09:40:49 am

@BlueHazzard, good job and good tutorial. :)

Title: Re: Showing vector elements in debugger
Post by: nji on June 23, 2017, 10:11:41 am

Yes, I do agree!  :)

So I took my clean c:b 16.01 (with mingw 4.9.2) and retraced your steps.

First try I left the two original files __init__.py (empty) and printers.py.
As I don't have any stl.gdb file anywhere, I inserted the init code as
"Debugger initialization commands"

Code

python
import sys
sys.path.insert(0, 'C:\Program Files (x86)\CodeBlocks\MinGW\share\gcc-4.9.2\python/libstdcxx/v6')
from printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
end

Also "Enable watch script" disabled.

When I try to debug your code it doesn't work:
Message (translated from German by me):

Code

"gdb.exe - systemerror.
The program cannot be startet, as python27.dll is missing on your computer."

And indeed, I searched for the file: it is nowhere.
Looks like you have done some extra steps ... ?
(I checked: When I change back to original gdb debugger works fine again.
Without pretty printing of course)

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 23, 2017, 10:15:35 am

from ollydbg in http://forums.codeblocks.org/index.php/topic,11301.0.html

Quote

You must install Python 2.7.5 release 32bit version on your system, as my build was linked to this python release.

so you need to install python 2.7.5
I probably had installed it previously...

Title: Re: Showing vector elements in debugger
Post by: nji on June 23, 2017, 10:21:56 am

In the link you provided in http://forums.codeblocks.org/index.php/topic,21998.msg149716.html#msg149716 (http://forums.codeblocks.org/index.php/topic,21998.msg149716.html#msg149716)
it was not necessary to install python?
As the the missing file is included in there...
But ... as it seems ... that way didn't work ... at least at me.
What I mean: If one installs c:b ... is it necessary to install python before, if gdb is python-enabled?
(To my experience it's best to install as few as possible)
Questions over questions ...  :-\

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 23, 2017, 10:35:18 am

Quote

What I mean: If one installs c:b ... is it necessary to install python before, if gdb is python-enabled?

codeblocks does not need python... gdb needs python. This are two separate projects. Codeblocks can not provide support for all things... And if codeblocks has to ship dlls for all possibly needed additional programs, the purpose of dlls is circumvented...

I had python installed previously for using it to program in python, so i don't had to install it. A bit of self thinking and googling solves this kind of problems in 2 sek.

i updated my previous post.

Title: Re: Showing vector elements in debugger
Post by: nji on June 23, 2017, 10:46:46 am

You're so right ... and a bit of self thinking and read what I wrote would keep you from being impolite.

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 23, 2017, 11:05:56 am

Quote

But ... as it seems ... that way didn't work ... at least at me.

does it work after installing python? If not what is the error you are getting?

Title: Re: Showing vector elements in debugger
Post by: nji on June 23, 2017, 11:52:26 am

I won't install python. (Reason for this ... see above).

If someone is trying to get rid of the M$ trap, you may tell him:
No, the debugger doesn't work at codeblock.
This is not our problem.
But you can try to install this & that to your system, and see what it makes to it.

This thinking is exactly what makes M$ success. Greetings.

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 23, 2017, 12:08:57 pm

@ollydbg:
does it make sense to provide the python dll within your gdb download? Are there dependencies to other dlls (from python27.dll to other) too?
What if there is a python27.dll in the bin folder and one in the system folder? What version gets picked?
I see the frustration of the OP and i would like to do something against it...

Title: Re: Showing vector elements in debugger
Post by: nji on June 23, 2017, 12:19:20 pm

Thank you for that.  :) :)

You're right ... frustration ... but not mainly because I can't see this f*** test[1],
but because it seems so clear to me that it has to be some kind of "convenient" to have any chance.
That was (to my opinion) the ONLY reason why M$ overcame Linux in the 80ies.
Not quality (for sure), not safety (2xsure), ... but convenience.

Quote from: BlueHazzard on June 22, 2017, 11:25:51 am

See it as learning.. If you know the things behind all this you will get a better programmer

I firmly disagree to that.
I want to focus on my problem, not on the internals of my tools.
To my experience it even keeps you from doing good work if you have to dig too much into side things.

[Edit: Not to talk about the deterent effect on potential beginners]

Please take this thread as my (small) contribution to help.
As long as I'm a newbie.

[Edit:
P.S.
Still one can use printf for debugging.
In times when Radeon RX 470 GPUs are used for making Bitcoins,
with c:b we are practicising ... no, not agile ...but ... amish software development and toolchain config.   ;) ;)
SCNR. NOT meant to offend.]

Title: Re: Showing vector elements in debugger
Post by: nji on June 24, 2017, 11:29:38 am

One should hope, that in the next release of c:b debugging will work.
As in the actual one (16.01) in the packaged mingw the gdb was not python enabled, but in the actual tdm package it is, with everything included that is in need.
So hopefully the devolopers of c:b will have a look that this chain will work, without having to install this and that, patching here and there.
Does this message reach them?

Title: Re: Showing vector elements in debugger
Post by: stahta01 on June 24, 2017, 03:00:32 pm

Quote from: nji on June 24, 2017, 11:29:38 am

One should hope, that in the next release of c:b debugging will work.
As in the actual one (16.01) in the packaged mingw the gdb was not python enabled, but in the actual tdm package it is, with everything included that is in need.
So hopefully the devolopers of c:b will have a look that this chain will work, without having to install this and that, patching here and there.
Does this message reach them?

I see two clear solutions to nji "Problem".
1. One his proposed solution to have the next release have an gdb python enabled with what is needed to debug.
2. Stop releasing the mingw version of the CB windows installer.

Tim S.

Title: Re: Showing vector elements in debugger
Post by: nji on June 24, 2017, 03:38:11 pm

While I don't see why your option (2.) helps.

As it shifts the responsiblity for a basic working system to the user (= make it even more unconvenient).
Especially (as the experience in this thread shows) as debug-enabling is not simply done by replacing the binaries.
Even higher hurdles for potential migrants from M$/ beginners.

As the actual tdm package (with python enabled gdb) is used in the nightlys: Are there any experiences?

You set "Problem" in paranthesis.
How shall I take that?
No "Problem" for professional like you?  ;)

Title: Re: Showing vector elements in debugger
Post by: stahta01 on June 24, 2017, 03:41:24 pm

Quote from: nji on June 24, 2017, 03:38:11 pm

While I don't see why your option (2.) helps.

As it shifts the responsiblity for a basic working system to the user (= make it even more unconvenient).
Especially (as the experience in this thread shows) as debug-enabling is not simply done by replacing the binaries.
Even higher hurdles for potential migrants from M$/ beginners.

As the actual tdm package (with python enabled gdb) is used in the nightlys: Are there any experiences?

You set "Problem" in paranthesis.
How shall I take that?
No "Problem" for professional like you?  ;)

I do NOT use the debugger very much; so, it is no problem for me.
Maybe I should have put your name in quotes; because I meant to imply it was NOT a CB IDE problem.
But, is instead a CB MinGW packaging problem.

Tim S.

Title: Re: Showing vector elements in debugger
Post by: nji on June 24, 2017, 04:16:38 pm

As I'm quite a newbie to c:b, mingw etc. (a "M$ migrant"  ;)) I don't know how the development is organized here.
But - see the experience in the thread - to me it seems not so much a packaging problem, but a kind of configuration problem (as just replacing the debugger from the c:b 16.01package to an actual one does not work, although python enabled and included).

I do not use the debugger very much too - only in the (very very few  ;)) cases when something doesn't work as I meant it.

Title: Re: Showing vector elements in debugger
Post by: stahta01 on June 24, 2017, 04:19:22 pm

Quote from: nji on June 24, 2017, 04:16:38 pm

As I'm quite a newbie to c:b, mingw etc. (a "M$ migrant"  ;)) I don't know how the development is organized here.
But - see the experience in the thread - to me it seems not so much a packaging problem, but a kind of configuration problem (as just replacing the debugger from the c:b 16.01package to an actual one does not work, although python enabled and included).

I do not use the debugger very much too - only in the (very very few  ;)) cases when something doesn't work as I meant it.

Please read the CB Faqs.

Tim S.

Title: Re: Showing vector elements in debugger
Post by: nji on June 24, 2017, 04:22:53 pm

As soons as I've finished "The Three Towers".

Title: Re: Showing vector elements in debugger
Post by: stahta01 on June 24, 2017, 04:36:03 pm

Quote from: nji on June 24, 2017, 04:22:53 pm

As soons as I've finished "The Three Towers".

I am going to ignore you from now on as a waste of time.

Tim S.

Title: Re: Showing vector elements in debugger
Post by: nji on June 24, 2017, 05:11:01 pm

What a pity for you.  :)

So you will never understand why to point blanket to the FAQ isn't very sensible after I explained in detail.

But maybe you're right ... it looks to be a "waste of time" with you.

Title: Re: Showing vector elements in debugger
Post by: stahta01 on June 24, 2017, 06:22:06 pm

Quote from: nji on June 24, 2017, 05:11:01 pm

What a pity for you.  :)

So you will never understand why to point blanket to the FAQ isn't very sensible after I explained in detail.

But maybe you're right ... it looks to be a "waste of time" with you.

Please read the rules before you are banned!
http://forums.codeblocks.org/index.php/topic,9996.0.html (http://forums.codeblocks.org/index.php/topic,9996.0.html)

Title: Re: Showing vector elements in debugger
Post by: nji on June 24, 2017, 06:39:05 pm

Banned?  :-\

Will you come with me?

---

Usually I don't explain my points ...
But for you I will do an exception:
Yes, I will take you for serious ...
... as soon as you do mature.
I always tried to explain/ to give reason for what I wrote above.
I can't imagine of anything more revealing weakness than the threat of a bann.
Oh man ...

Title: Re: Showing vector elements in debugger
Post by: sodev on June 24, 2017, 07:23:00 pm

CodeBlocks is not a compiler, its "just" an IDE, not like Visual Studio that is both. And its not the only one like that, take a look at Eclipse, Netbeans, i dont think they even have packages that include a compiler.

Personally i never downloaded a CodeBlocks package including a compiler, i havent downloaded a CodeBlocks since years actually because i compile it myself from svn. So i dont mind if they drop these packages at all if it helps to stop codecompletion from stopping to work as soon as i type auto.

But im not a cool kid from school anymore, im not coding in cool languages that dont need uncool shit like a compiler, so i might be a little outdated how cool coding works today. Do i still need a keyboard?

Title: Re: Showing vector elements in debugger
Post by: nji on June 24, 2017, 07:37:48 pm

I fear I'm spoiled by all my M$ years.

Maybe I too should try to get used to do what I called the amish way.
(Which wasn't meant derogative for the Amish at all. Just the opposite.)

But, as I pointed out quite often in this thread, if non-commercial development will have a chance it has to become convenient to use.
The long-year insiders don't seem to understand that.

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 25, 2017, 12:44:15 am

I honestly don't want to discuss this any future...
Just to make some points clear: I to have the opinion that codeblocks should ship as a full functional build environment with enabled debugger ecc. But this will not happen soon...

@nji
You have to understand, that codeblocks is just a IDE. Codeblocks can be used with gdb as debugger or with cdb as debugger
Codeblocks can be used with gcc compiler or with visual studio compiler or with borland compiler ecc...
Codeblocks can be used on windows, mac or linux

Codeblocks can not provide a distribution for any possible combination. Some user uses a older gdb someone uses a newer gdb, someone with c++ someone with fortran ecc.

The philosophy is not to provide a full development environment (like visual studio), but a pretty good text editor with the possibility to integrate other tools (like gdb and gcc), not provide support or help for this tools (but provide support for the integration). GDB and GCC are separate projects. And they need also other separate projects like python. Everyone does what they can and relate to the other project for support. M$ does not use this philosophy because they have everything in house (visual studio ide, visual studio compiler, M$ basic as scripting ecc.), but they are a $$$$M Dollar cooperation and not 5 developer that do this in their free time.
 Python makes a good scripting engine so gdb decides to use it in his project. Now gdb has a dependency to python, but has not the responsibility to provide a binary. On linux the resolving of this dependencys is no problem, because it uses a packet manager that resolves this problems for you. On windows you have to do this by your hand (don't blame codeblocks for this, because it is not the responsibility of codeblocks to resolve installation dependencys).

You try to use a feature that is not present in this release of CB.
I think i provided you with enough support to integrate it on your system (and i am willing to help you even more, until we have all steps together to make a nice tutorial for other people, this is the way how open source work, all cooperate and help to resolve problems). If you are not willing to resolve the dependency i feel a bit fooled for all the time i invested to help you, but this is ok, it was my decision...

Even more OT: All in all this work in resolving problems and using a old stylish IDE looks uncool for young people (i am <<30, so i count me as young). Young people use cool things like electron and java script. But the result of this cool things is bullshit. A telephony application (i look at you discord) that needs 170MB Installation, 146MB RAM and constantly 0.4% cpu on idle versus a uncool old in c and c++ written qTOX that uses 50MB RAM 0% cpu and 60MB installation, and if you use a even more uncool TOX you only need 5MB of RAM and all this uncool tools can better telephone then discord...

Title: Re: Showing vector elements in debugger
Post by: killerbot on June 25, 2017, 09:42:01 am

Dear all.

please keep  calm and continue debugging ;-)

You know, everyone here is right with fair remarks, but we are all wrong too.

Most important, we develop CB, aka an IDE, that means, not the compiler, not the debugger. BUT ... ( I will come to the but shortly). For

convenience on windows we ship the MinGw package (which is a port of gcc, but it brings also problems), as mentioned we could switch too TDM. However it seems TDM John" is unreachable (which probably means he is busy with other things) and the TDM package is also getting outdated (it is at gcc 5.1.0), so it seems we might loose this option too (note that this is the compiler we use to build the nightly builds).

Let me first explain how I use CB, I always build it from svn, and I use it on linux (I boot up windows for 2 things, installing a game (and with some luck even play that game), and building nightlies). As such on linux I have to install the compiler, debugger myself, which is very easy to do (upgrading a compiler however is not).
I also sometimes get lost with the "enable scripts" versus do not enable the scripts but have a gdb-python pair.
And yes me too, I hardly need a debugger.
It is a pity indeed that gdb does not have such things build in (I myself can get angry on that, but I will spare you my rant).

FIRST CONCLUSION : many people have asked about this, so I think it deserves a link on our homepage to an up to date dedicated page on our wiki. Where everything is clearly explained on how to do it (with example of code snippets/programs, so the reader can verify he gets similar results).

SECOND CONCLUSION : we need to start deciding what "convenience" package to ship in the next release.

Now let me address the BUT. The customer is always right! As good as our CB is, what counts is the user experience, no discussion about that, period. We can point to windows, gdb, python whatsoever. We need to at least propose a "recipe" to get to a good user experience (and we can do such thing a little bit with our convenience package. The user use the IDE for 2 things at minimum:

• write code
• debug code

The fact that the user used to have an expensive MS Visual Studio is a non argument. It is not the MSVS user experience that counts in this discussion it is OUR CB experience that matters.
It is the total user experience that counts, and will make a happy user, or aan user which decides to drop CB and look further.
Imagine you have a nice app on your phone, but the backend it talks too really sucks, no matter how nice and shiny and performant that app might be (even assume it is bug free), the experience will be crap due to that backend, and the user will drop it and look for other alternatives.

I have been evangelizing CB a lot in the past, I still do, but I an giving fair information, because if I do not from the start, in the end I end up like a fool, and let me tell you why, again it is all about user experience, and these areas where I have to say upfront the state  of the functionality (or lack of current state) are in order of what I have see from people complaining or in the end not willing to use CB (despite of all the other great features it has):

• code completion      <== we loose big time here wrt competition
• refactoring
• debugger

As long as the first 2 are in the current state, I noticed it is nearly impossible to convince for example an Eclipse user to even consider CB :-(
And yes I could try to improve it myself, but our current completion engine is dead, it can not solve the problems anymore, we need a different approach, and we have someone kindly working on an alternative one, and I am thinking of having a nightly (separate) build with it, so we can have more feedback, but even then it is 1 person at this moment so his time is also limited.
So yes the more people who can help out, test, provide patches, would be very nice. That's the good thing about open source, but it is also the downside, if nearly nobody steps up to help out things start to go slower and slower. And I have to pleed guilty myself, I still get up to the project management part of CB, the nightly builds but my commits have also been very low the last 2 years, because my spare time is a scarce resource.

So to all, please be constructive, though your statements might all be 100% correct, we need to aim for a good user experience, and try to bring that, not by saying we are only this, or that is not our problem. We need to look at the bigger picture.

PROPOSAL:
- this thread consists out of many suggestions, let's try them out
- use a nightly build and install TDM-GCC 5.1.0 package
- install python
- verify if it works
- let's discuss the problems in a positive way
- so we can end up with hopefully a working solution
- document the solution and give it a clear spot on our homepage
- in case we end up with a good result, as far as I am concerned (but I can't decide on just by myself) this could be the trigger for a new release (based upon whatever convenience package we end up with)
So I would like to kindly ask our OP to help out (I think you did not want to install python, in that case I am afraid there will be no solution, so please reconsider, pretty please), so some of the burden will be on your shoulders, but if it works out, I can tell you, you will feel happy and proud and that open source feeling.
And I promise that I will boot up my windows machine and try the same code snippets out myself, so we can share our findings, our frustrations, but we will turn them into something positive.

Please , let's work together, we are all right, but NOW LET'S IMPROVE THE USER EXPERIENCE.
Sorry for shouting ;-)

PS : let's not start a code completion discussion here, let's focus on getting e better debugging experience by bundling all the good things we have.[/list]

Title: Re: Showing vector elements in debugger
Post by: nji on June 25, 2017, 11:36:54 am

First of all:
It was not my intend to offend anyone.
As a matter of fact I am grateful to those who are the reason that there exists
this fine independent alternative to $$.
Thank you for that indeed.  :)
Being a M$-migrant all I can contribute so far is the experience "one" does
if one comes from that way. Deterrent, pleasant, ...
I didn't "give way" because I wanted to contribute just that.
Again: I didn't want to annoy anyone.

I'm sorry to have to disappoint you (asked to please reconsider) to install python.
I really have a reluctance to install more scripting ability to my system.
A potiential gate for anything ... that I don't need at all.
(Maybe I should mention that first thing I did after installation of Win7 was
to turn off every unwanted services, deinstall certain windows components,
closed all holes etc.).

But this way debugging works (more or less):
If one substitutes the gdb binaries (and probably nescessary sub folders etc.)
with the newer tdm gcc 7.9.1. (http://sourceforge.net/projects/tdm-gcc/files/GDB/gdb32-7.9.1-tdm-1.zip/download (http://sourceforge.net/projects/tdm-gcc/files/GDB/gdb32-7.9.1-tdm-1.zip/download)),
along with activating the scripts in cb's debugger config (see description above)
then it works ... nearly. (You can see the vector and the unfolding of its members,
but you can't watch a special index directly - test[42]).
So there is something wrong somewhere.

If with next release of cb it comes to the decision to drop mingw support
and to leave it for the windows user too to install compiler (and to manage
the adaption) I probably will stay with c:b (As there are reasons why I did't
decide for the other free options).
But probably cb will put off potential windows migrants and leave them in the arms
of the convenient $$-octopus.

[Edit:

Quote from: BlueHazzard on June 25, 2017, 12:44:15 am

Even more OT: ... that needs 170MB Installation, 146MB RAM and constantly 0.4% cpu on idle versus a uncool old in c and c++ written qTOX that uses 50MB RAM 0% cpu and 60MB installation...

100% agree.
But to my experience (as M$-migrant, did I mention?) also in "here":
Using wxWidgets produces a minimal size of several MB, while a typical
(not too simple) application of mine using MFC are only few 100kB.
"Nobody sane cares about that" was the answer I got in a forum.
Or - maybe a more subtle example - as I wanted to change from MFC
containers to modern standard lib ones, and discovered what kind of
absurd pull ups you have to do if you want to avoid unnecessary initialization.]

Title: Re: Showing vector elements in debugger
Post by: ollydbg on June 25, 2017, 03:51:37 pm

Quote from: BlueHazzard on June 23, 2017, 12:08:57 pm

@ollydbg:
does it make sense to provide the python dll within your gdb download? Are there dependencies to other dlls (from python27.dll to other) too?
What if there is a python27.dll in the bin folder and one in the system folder? What version gets picked?
I see the frustration of the OP and i would like to do something against it...

Copying only a dll file is not enough, you have to copy all the folders(such as the folder named "Lib" under python installed folder) to your GDB's bin folder. This will make the distribution a lot bigger, my personally python have a lot of non-standard packages installed in the "Lib" folder, so I don't want to to distribute the python, installing python is quite simple under Windows, just download the official python installer.

Title: Re: Showing vector elements in debugger
Post by: stahta01 on June 25, 2017, 05:50:32 pm

Quote from: nji on June 24, 2017, 06:39:05 pm

Banned?  :-\

Will you come with me?

---

Usually I don't explain my points ...
But for you I will do an exception:
Yes, I will take you for serious ...
... as soon as you do mature.
I always tried to explain/ to give reason for what I wrote above.
I can't imagine of anything more revealing weakness than the threat of a bann.
Oh man ...

If you do NOT consider it worth your time to look at the FAQs; then, I think you never read the rules!

Reading the rules after you are banned is NOT very useful.

Tim S.

Title: Re: Showing vector elements in debugger
Post by: nji on June 25, 2017, 06:00:39 pm

@stahta01:
I couldn't have expressed it better.  :)

Quote from: ollydbg on June 25, 2017, 03:51:37 pm

Copying only a dll file is not enough, you have to copy all the folders(such as the folder named "Lib" under python installed folder) to your GDB's bin folder. This will make the distribution a lot bigger, my personally python have a lot of non-standard packages installed in the "Lib" folder, so I don't want to to distribute the python, installing python is quite simple under Windows, just download the official python installer.

Does this mean that using the gdb binaries (v.7.9.1) from http://tdm-gcc.tdragon.net/download (http://tdm-gcc.tdragon.net/download) (at the bottom) will never be sufficient (although "includes Python support")?
I took this and copied everything into the existing structure ... and it works ... nearly (see description above).

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 26, 2017, 10:27:37 am

i tested now with the gdb from the tdm site and here are my results:

Code

Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target: 
Debug
Adding source dir: ****rerreer\
Adding source dir: ****rerreer\
Adding file: ****rerreer\bin\Debug\rerreer.exe
Changing directory to: ****rerreer/.
Set variable: PATH=.####

[debug]Command-line: TDM-GCC-32\bin\gdb.exe -fullname -quiet -nx -args ****rerreer/bin/Debug/rerreer.exe
[debug]Working dir : ****rerreer

Starting debugger: TDM-GCC-32\bin\gdb.exe -fullname -quiet -nx -args ****rerreer/bin/Debug/rerreer.exe
done

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

Setting breakpoints

[debug]Reading symbols from ****rerreer/bin/Debug/rerreer.exe...
[debug]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 200
[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]> source TDM-GCC-32\bin\stl.gdb
source TDM-GCC-32\share\gcc-4.9.2\python\wx\wx_print.py
[debug]>>>>>>cb_gdb:register wxWudgets printer
[debug]> directory ****rerreer/
[debug]>>>>>>cb_gdb:
[debug]> break "****rerreer/main.cpp:10"
[debug]Source directories searched: ****rerreer;$cdir;$cwd
[debug]>>>>>>cb_gdb:Breakpoint 2 at 0x4013b2: file ****rerreer\main.cpp, line 10.

Source directories searched: ****rerreer;$cdir;$cwd

[debug]> run
[debug]>>>>>>cb_gdb:
[debug]> info frame
[debug]Starting program: ****rerreer\bin\Debug\rerreer.exe 

Child process PID: 7072

[debug][New Thread 7072.0x11a0]
[debug]Breakpoint 2, main () at ****rerreer\main.cpp:10
[debug]****rerreer\main.cpp:10:137:beg:0x4013b2
[debug]>>>>>>cb_gdb:Stack level 0, frame at 0x28ff30:

At ****rerreer\main.cpp:10

[debug]> bt 30
[debug] eip = 0x4013b2 in main (****rerreer\main.cpp:10); saved eip = 0x4010fd
[debug] source language c++.
[debug] Arglist at 0x28ff18, args: 
[debug] Locals at 0x28ff18, Previous frame's sp is 0x28ff30
[debug] Saved registers:
[debug]  ebx at 0x28ff0c, ebp at 0x28ff18, esi at 0x28ff10, edi at 0x28ff14, eip at 0x28ff2c
[debug]>>>>>>cb_gdb:#0  main () at ****rerreer\main.cpp:10
[debug]>>>>>>cb_gdb:
[debug]> whatis test
[debug]type = std::vector<double>
[debug]>>>>>>cb_gdb:
[debug]> output test
[debug]std::vector of length 1, capacity 1 = {22.440000000000001}>>>>>>cb_gdb:
[debug]> next
[debug]****rerreer\main.cpp:12:187:beg:0x4013ce
[debug]>>>>>>cb_gdb:

At ****rerreer\main.cpp:12

[debug]> whatis test
[debug]type = std::vector<double>
[debug]>>>>>>cb_gdb:
[debug]> output test
[debug]std::vector of length 2, capacity 2 = {22.440000000000001, 1.3795933261199322e-306}>>>>>>cb_gdb:
[debug]> bt 30
[debug]#0  main () at ****rerreer\main.cpp:12
[debug]>>>>>>cb_gdb:
[debug]> whatis test[0]
[debug]type = double
[debug]>>>>>>cb_gdb:
[debug]> output test[0]
[debug]22.440000000000001>>>>>>cb_gdb:
[debug]> whatis test[1]
[debug]type = double
[debug]>>>>>>cb_gdb:
[debug]> output test[1]
[debug]1.3795933261199322e-306>>>>>>cb_gdb:

so all is working for me... I don't understand why it is not working for you...
Can you try do redo all my steps i posted above but use the tdm gdb?
Also can you create a new project and try my sample code i posted above?

Title: Re: Showing vector elements in debugger
Post by: nji on June 26, 2017, 11:33:17 am

Maybe there is a kind of confusion beginning to creep in now.

I already tested both versions of gdb:

The one from TDM
https://sourceforge.net/projects/tdm-gcc/files/GDB/gdb32-7.9.1-tdm-1.zip/download (https://sourceforge.net/projects/tdm-gcc/files/GDB/gdb32-7.9.1-tdm-1.zip/download)
works ("humbling") for me too, as I posted here
http://forums.codeblocks.org/index.php/topic,21998.msg149717.html#msg149717 (http://forums.codeblocks.org/index.php/topic,21998.msg149717.html#msg149717)

And the one from ollydbg
http://sourceforge.net/projects/gdbmingw/files/gdb2016-01-30.zip/download (http://sourceforge.net/projects/gdbmingw/files/gdb2016-01-30.zip/download)
lets miss the python27.dll
see
http://forums.codeblocks.org/index.php/topic,21998.msg149741.html#msg149741 (http://forums.codeblocks.org/index.php/topic,21998.msg149741.html#msg149741)

The reason why TDM gdb works for you (as the one from ollydbg) probably is
because you installed python separately.

[Edit:
If you would de-install your python distr, maybe (... maybe) you would have the same effect than I.]

BTW:
As TDM gdb (python-enabled) works (more or less) for me (without having
installed python anywhere) I do doubt that it is necessary to install python separately.
For me it looks like a kind of "cooperation problem" (IDE, gdb, ...?).
And the way I did now (just copying the binaries into the existing structure)
for sure is no good.

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on June 26, 2017, 11:57:11 am

Quote

As TDM gdb (python-enabled) works (more or less) for me (without having
installed python anywhere) I do doubt that it is necessary to install python separately.
For me it looks like a kind of "cooperation problem" (IDE, gdb, ...?).

i think it has something to do with your code (you never mentioned that you tested my code) or something with the python scripts.
the things what baffle me is the output of your debugger..

Code

[debug]>>>>>>cb_gdb:
[debug]> whatis diffVector
[debug]type = std::vector<double, std::allocator<double> > &
[debug]>>>>>>cb_gdb:
[debug]> output diffVector
[debug](std::vector<double, std::allocator<double> > &) @0x28fecc: {<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 = 0x1c19678, _M_finish = 0x1c19678, _M_end_of_storage = 0x1c80850}}, <No data fields>}>>>>>>cb_gdb:
[debug]> whatis diffVector [2]
[debug]type = std::vector<double, std::allocator<double> >::reference
[debug]>>>>>>cb_gdb:
[debug]> output diffVector [2]
[debug](__gnu_cxx::__alloc_traits<std::allocator<double> >::value_type &) @0x147f660: 1.3795933261199322e-306>>>>>>cb_gdb:

As you can see it is different from my output:

Code

[debug]> whatis test[0]
[debug]type = double

vs

Code

whatis diffVector [2]
[debug]type = std::vector<double, std::allocator<double> >::reference

Also what does show the watches window for this:

Code

[debug](__gnu_cxx::__alloc_traits<std::allocator<double> >::value_type &) @0x147f660: 1.3795933261199322e-306>>>>>>cb_gdb:

?

Title: Re: Showing vector elements in debugger
Post by: nji on June 26, 2017, 12:28:14 pm

Actually I used exactly your code

Code

    vector<double> test;
    test.push_back( 22.44 );
    test.push_back( 1.3795933261199322e-306 );
    test[1];

And then the debugger's output is

Code

[debug]> whatis test
[debug]type = std::vector<double, std::allocator<double> >
[debug]>>>>>>cb_gdb:
[debug]> output test
[debug]std::vector of length 2, capacity 2 = {22.440000000000001, 1.3795933261199322e-306}>>>>>>cb_gdb:
[debug]> whatis test[1]
[debug]type = std::vector<double, std::allocator<double> >::reference
[debug]>>>>>>cb_gdb:
[debug]> output test[1]
[debug](__gnu_cxx::__alloc_traits<std::allocator<double> >::value_type &) @0x1bee910: <error reading variable>>>>>>>cb_gdb:

Title: Re: Showing vector elements in debugger
Post by: oBFusCATed on June 29, 2017, 03:00:35 pm

Quote from: killerbot on June 25, 2017, 09:42:01 am

I also sometimes get lost with the "enable scripts" versus do not enable the scripts but have a gdb-python pair.

These are going away, soon. I'll just remove them as soon as I find some free time. They are useless anyway.

For gdb troubles: if we ship python enabled gdb then we'll need to ship our own version of python or modify the installer to start an installation of python itself.
BTW one of the gdb windows builds had some stub gdb.exe which was modifying env variables and then the only thing it did was to start the real executable. This version doesn't work too well (the pausing command doesn't work)!

p.s. unfortunately I don't have time nor desire to work on c::b on windows.

Title: Re: Showing vector elements in debugger
Post by: BlueHazzard on July 09, 2017, 11:27:17 pm

@nji
any news on this?
I honestly have no idea what is going on on your system... I don't think this has anything to do with codeblocks and its configuration, but something with gdb and compiler combination?

Title: Re: Showing vector elements in debugger
Post by: TobiasA on December 20, 2017, 08:36:23 pm

Well, the solution might be pretty simple...

Go to
http://forums.codeblocks.org/index.php/topic,22325.msg151987.html#msg151987
and check if you have disabled the startup scripts for GDB.

I am using TDM GCC as well and fell for the same... Came across this thread during my search and thought it might be interesting for you.
TDM GCC works right out of the box as it seems, there are just some hooks placed wrong in some online tutorials from some years back...