Debug watches problem (Incomplete type)

[Multinode Nick]

Hi,

I tried C::B for a week now, I left Microsoft for good without any regret. So I installed the latest C::B last week with wxWidgets 2.6.3. (gbd.exe is V6.3)

At this point I'm testing all the functionnalities and I try to undestand how every single object works, but I have a issue here about the debug Watches. I'm unable to see the state of some variables (but not all) of my wxWidget objects. My code works well, my bitmap rotate (180deg) as expected, I just want to explore inside the beast...

I'm debugging these lines:

void NewDialog::OnButton1Click(wxCommandEvent& event)
{
   wxBitmap TempBMP = StaticBitmap1->GetBitmap() ;

   wxImage TempImage = TempBMP.ConvertToImage();
   wxImage TempBMP2;

   wxPoint Pt(160,100), PtOffset(0,0);

   for(double i=0.0; i<3.14159265; i+=0.1){
      TempBMP2 = TempImage.Rotate(i,Pt, false,&PtOffset);
      StaticBitmap1->SetBitmap(TempBMP2);   
   }
   Update();
}


I have a breakpoint beside Update(); to be sure everybody is well initiated. But the Watches window shows me this:

i=0
TempBMP= <incomplete type>
TempBMP2= <incomplete type>
TempImage= <incomplete type>
Pt
   x = 160
   y = 100

Is there any problem 50cm in front of my screen ;-), or I really spotted something?

Thanks!

Nick

[David Perfors]

You really spotted something that others also have spotted
I have the same problem, but the problem is in the debugger (gdb) and not in Code::Blocks.
To support those types you have to add them to the debugger.
How? I don't know.
Code::Blocks has included wxString, but when I tried my own type of string, I didn't manage to watch it.

I think this is a plus for Microsoft, they have a very nice debugger (and codecompletion...)

[takeshimiya]

they have a very nice debugger

so, has anyone tested if this works from codeblocks when using vc and cdb?

[David Perfors]

I didn't... It is my experience with visual studio....

[Multinode Nick]

Thank you mispunt,

But if you're right, how do you debug your developments without a good Watches window? It must be very time consuming without it...

Like as you said, I noticed that gdb seems to manage wxString and wxPoint but it's blind in front of wxBitmap and wxImage.

wxWidgets seems to be well integrated in Code::Blocks, but how can we use it efficiently if we cannot debug our interfaces?

[artoj]

Like as you said, I noticed that gdb seems to manage wxString and wxPoint but it's blind in front of wxBitmap and wxImage.

wxWidgets seems to be well integrated in Code::Blocks, but how can we use it efficiently if we cannot debug our interfaces?

New watch types can be added with the debugger scripts. In Code::Blocks' installation, the file which gets executed at the start of the debugging session (and registers the types) is in share\CodeBlocks\scripts\gdb_types.script. And the language used is called Squirrel, more info at the Wiki.

But if you're right, how do you debug your developments without a good Watches window? It must be very time consuming without it...

The questions should be, "how do I debug something without any debugging features available", which is the Windows XP 64-bit edition with the current Mingw.

[dmoore]

the incomplete type is a GDB bug. you just CAN'T inspect some variables (you can see it in the debuggers console window if you have it switched on)

you could try an older version of GDB - I've read that 5.x versions don't have the incomplete type problem (but they do have other problems and may not work with CB at all...)

[David Perfors]

Thank you mispunt,

But if you're right, how do you debug your developments without a good Watches window? It must be very time consuming without it...

Like as you said, I noticed that gdb seems to manage wxString and wxPoint but it's blind in front of wxBitmap and wxImage.

wxWidgets seems to be well integrated in Code::Blocks, but how can we use it efficiently if we cannot debug our interfaces?

It is a real pain to debug with GDB (my opinion). When I debug, I put messages on a console, and I step through code to see where things go wrong. That is no problem in code that I own, but in code of wxWidgets or some other lib, it is a real pain....
Perhaps we can work on a set of wxWidgets types that could be watched by C::B/GDB...

[mandrav]

the incomplete type is a GDB bug. you just CAN'T inspect some variables (you can see it in the debuggers console window if you have it switched on)

It's actually the combination of the gcc version used to compile the program and the gdb version. After all, if you think about it, the debugger only knows about the debug symbols the compiler has put in the binary you 're debugging .

If you google for this issue you will find lots of references, like this similar post.

[dmoore]

the incomplete type is a GDB bug. you just CAN'T inspect some variables (you can see it in the debuggers console window if you have it switched on)

It's actually the combination of the gcc version used to compile the program and the gdb version. After all, if you think about it, the debugger only knows about the debug symbols the compiler has put in the binary you 're debugging .

If you google for this issue you will find lots of references, like this similar post.

I'll accept that. my point was that no amount of hacking in CB will get around it. unlike wxString, which actually returns pointer/member info when you write "output str" even if it isn't quite what you want, wxBitmap returns nothing when you write "output bmp". I suspect that the complexity of the ABSTRACT/DYNAMIC macros used to declare the wxBitmap type is the cause.

BTW I finally figured out how to display debugger output from fortran programs for variables in modules. unfortunately the "output" command refuses to cooperate and I can only use the gdb "x" command with appropriate formatting. This will be a pain to get working in the watch (probably not worth the effort)

EDIT: you probably know this already, but gdb has a little "macro" language allowing you to define your own commands. link: http://computing.ee.ethz.ch/sepp/gdb-6.5-mo/gdb_116.html#SEC228. maybe this could be used to handle some of the parsing work?

[Multinode Nick]

It's actually the combination of the gcc version used to compile the program and the gdb version. After all, if you think about it, the debugger only knows about the debug symbols the compiler has put in the binary you 're debugging .

Thank you Mandrav,

I made some searches to find the source and solve this problem, dmoore may be right with de dgb version so I tried another version, but without success. So I decided to build wxWidgets for Visual Studio to see if it could do more (I used it for 9 years so I'm still more efficient on this platform). 1 hour passed and 3GB were drained before I could test my sample on VC to finaly see what happened.

VC debugger goes a little bit deeper in the structure, it goes deep enough to see that wxImage (and many wx classes) use polymorphic objects to store its data. After that level, the MS debugger gets lost and seems unable to do more with it (even with forced casts). So there is no reason to go back to this demonic compiler ;-)...

Is it possible that dgb doesn't receive polymorphic classes symbols from libraries? I would explain everything...

[mandrav]

Have you tried with gdb 5.2?

[Multinode Nick]

Have you tried with gdb 5.2?

Hi mandrav, sorry for the late response I wasn't at my office for few days.

No I didn't try it, You think an older version will do more that a more recent one?

For my opinion, gdb did as well as vc so it could be enough for me, I have productivity concerns here ;-) This problem did happen only on polymorphic stuff, I can live with that...

Thanks!

Nick