User forums > Using Code::Blocks

debug - plague of complaints continues

(1/2) > >>

Radek:
Okay, I am able to get variables in the watches window now.

(1) Complaint #1:


--- Code: ---class dvec
{
  double *data;
  int        size;
  ...
};

--- End code ---

Is it possible to see the contents of data? I am able to see only the address. Clicking on the "raw data" button gives gives me only the address again. All choices in the context menu are grayed, both in the watches window and in the raw data window. No chance to see *data as an array of doubles. No chance, really?

Complaint #2:

Okay, dvec is not as stupid as it seems to be and it can use user supplied buffer as its data. This could provide the values, at least for now, because the array of doubles can be dereferenced. Tracing though the testing program again, something seems to be wrong. Tracing once more and more carefully:


--- Code: ---dvec rv;

...

bool bb = rv.alloc(5);

--- End code ---

Returns true. Strange. Okay, I know the address of rv. Tracing into alloc(), this should be the same address but it is not, at least in the watches window. The dvec allocates correctly, sets its size but, on return, the size of rv is wrong in the watches window as well as the buffer address. Note: I have reloaded rv into the watches, so that it is not a problem of oudated data in the window.

Being completely desperate, I wrote a dump() routine:


--- Code: ---void dump( const dvec& vec )
{
  double *d = vec.data();

  printf("%5.1f  %5.1f  %5.1f  %5.1f  %5.1f\n",d[0],d[1],d[2],d[3],d[4]);
}

--- End code ---

I inserted dump() into the code and traced again. The output is as expected and it is correct so that this is not a gdb problem. Aye, aye, what I am doing wrong now? Debian, Gnome, svn 7932.

oBFusCATed:
1. This is limitation of the gdb/cli interface we are using, sorry. The only way to see the value is to add a separate watch
2. I'm not sure what is the question, be specific, please

Radek:
(1) Watching "rv.data" works, thanks, but I don't see a limitation. If the user can watch "rv.data", why the debugger interface cannot? Adding objects and then object members in a watches or local variables windows seems to be a bit unfortunate.
(2) I made the dvec use a user supplied buffer. Then I watched the buffer but the values there did not change even if they should. Searching for a reason, I found a strange behavior or the address of the instance of dvec as well as the strange values of other class data items (the dvec size is an int but it is not shown correctly).

oBFusCATed:
1. It will be too complex and too slow, it will be fixed in the new gdb/mi plugin, someday.
2. Still don't understand.

Radek:

--- Code: ---#include <dvec.hpp>
#include <stdio.h>


int main()
{
  double dd1[] = { 0.0,  1.0, -2.0,  3.0, -4.0 };
  double dd2[] = { 1.0, -2.0,  3.0, -4.0,  5.0 };
  double dd3[] = { 0.0,  0.0,  0.0,  0.0,  0.0 };
  double dd;

  dvec     a,b,c;
  dvec::el e;
  bool     bb;

  bb = a.mkview(dd1,5);   // use dd1 for a data buffer of a, size = 5
  bb = b.mkview(dd2,5);   // use dd2 for a data buffer of b, size = 5
  bb = c.mkview(dd3,5);   // use dd3 for a data buffer of c, size = 5
  c  = a + b;

  ...

--- End code ---

Debug and watch dd3. On the line c = a + b; dd3 should change, but it does not. When watching c.data, the c.data does change as expected. In the meantime, I have met the dreaded "incomplete type" - when I compiled the library as release. Even if the test program is compiled as debug and even if the header dvec.hpp is available, dvec is now "incomplete type" and "there is no member named c.data". Does it mean that I must use either debug compiled and unoptimized libraries or I cannot debug because I won't see any library-defined data? I understand that with a release build I cannot trace into the library (or I get the assembler window) but I should see the data described in headers. Is the gdb API so rudimental? Complaint #3  ;D

Navigation

[0] Message Index

[#] Next page