Debugging and wxWidgets

[mmccarty12]

I have been having a problem for some time when I am trying to debug my wxWidgets projects.  When I attempt to view the value of a wxWidgets object, many will give a message saying it is undefined in this context, although I am in the function that uses/defines the object.  And when I comes to wxStrings, regardless of what is actually in the variable, when I try to output the value in the watch window all I get is "" for the value. 

Any suggestions?

wxWidgets 2.9.0 - Mono-Shared-Debug-OpenGL-Unicode-GTK
wxWidgets 2.9.0 - Mono-Static-OpenGL-Unicode-GTK
C::B SVN 6178.
CentOS 5.4

[oBFusCATed]

Can you try wx2.8.x? What is your gdb, can your try a newer nightly...

Does the watch variables work for the other types (your own for example)?

[mmccarty12]

Can you try wx2.8.x?

I have using 2.8.9 and 2.8.10 and the same situation comes up when using unicode/non-unicode, debug/release, shared/static.  Or any combination of the above.

What is your gdb,

GNU gdb Fedora (6.8-37.el5)

can your try a newer nightly...

This is the umpteenth version of C::B I have run.  I have another C::B running on a Suse machine that is RC8.02 and the same problems occur.

Does the watch variables work for the other types (your own for example)?

Yes, even wxWidgets objects like events show properly, until it gets to showing the string values. 
Like I said, many, but not all, of the objects do not display properly in the watch window.
One of my concerns is why.

[oBFusCATed]

Another thing you can do is to try gdb from the command line... or DDD, kdbg or something similar.

You can inspect the debuggers log for some problems ( settings -> compiler & debugger -> debugger -> show debugger's debug log)

[Pecan]

I can also confirm these problems with:

Windows7
wxWidgets 2.8.10,
gcc 4.3.1 Windows/unicode
GNU gdb 6.7.50 & 7.1

On occasion, examining a local wxString will cause gdb to crash.

[mmccarty12]

Another thing you can do is to try gdb from the command line... or DDD, kdbg or something similar.

{static npos = 18446744073709551615, static ms_cache =
   {cached =
      {
         {str = 0x7fffa61ad130, pos = 0, impl = 0, len = 18446744073709551615},
         {str = 0x7fffa61acf20, pos = 0, impl = 0, len = 18446744073709551615},
         {str = 0x7fffa61ad160, pos = 0, impl = 0, len = 18446744073709551615},
         {str = 0x126efaf8, pos = 0, impl = 0, len = 18446744073709551615},
         {str = 0x126efb58, pos = 0, impl = 0, len = 18446744073709551615},
         {str = 0x7fffa61ace40, pos = 0, impl = 0, len = 18446744073709551615},
         {str = 0x7fffa61acdc0, pos = 0, impl = 0, len = 18446744073709551615},
         {str = 0x7fffa61ad2b0, pos = 0, impl = 0, len = 18446744073709551615}
      },
      lastUsed = 7
   },
   m_impl = {static npos = 18446744073709551615,
               _M_dataplus =
               {<std::allocator<char>> =
                  {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields> },
                  _M_p = 0x126f6d28 "DEM 3-D 2010.0.0.0"
               }
   },
   m_convertedToChar = {m_str = 0x0, m_len = 0},
   m_convertedToWChar = {m_str = 0x0, m_len = 0},
   m_iterators = {ptr = 0x0}
}

As you can see, 7 lines up, where line starts _M_p, the value is eventually displayed.  But in the watch window in C::B, _M_p = 136 '\210' is displayed in C::B.
The problem is with the way C::B interprets(parses) the gdb output.  Not something I am doing wrong.  So I guess I have to post this as a bug, not ask what I can do to fix it.

[oBFusCATed]

mmccarty12: When you submit the bug, please tell me the id/number, so I can try it on the debugger branch.

[mmccarty12]

mmccarty12: When you submit the bug, please tell me the id/number, so I can try it on the debugger branch.

oBFusCATed: Here is the bug tracker number from Berlios Bug Tracker for C::B. 017191

[oBFusCATed]

mmccarty12:
Looking more thoroughly at the output it looks like your wx is compiled in STL compatibility mode (--enable-stl or something like that)

Here is the output of a simple wxString variable:

Code Select Expand


> output test
{
  <wxStringBase> = {
    m_pchData = 0x6916d8 L"\x69d9c8"
  }, <No data fields>}>>>>>>cb_gdb:


Can you provide a simple test project?

[Pecan]

I have been having a problem for some time when I am trying to debug my wxWidgets projects.  When I attempt to view the value of a wxWidgets object, many will give a message saying it is undefined in this context, although I am in the function that uses/defines the object.  And when I comes to wxStrings, regardless of what is actually in the variable, when I try to output the value in the watch window all I get is "" for the value.  

Any suggestions?

wxWidgets 2.9.0 - Mono-Shared-Debug-OpenGL-Unicode-GTK
wxWidgets 2.9.0 - Mono-Static-OpenGL-Unicode-GTK
C::B SVN 6178.
CentOS 5.4

I've found this happens when the variable being examined is associated with a return value (which is usually kept in a register) and gdb decides that the address of the variable/value is unreachable (which it is since it's in a register, not memory).

Example:

Code Select Expand


// ----------------------------------------------------------------------------
wxString ICCISPDlg::GetVerifyParms(const wxString& fname)
// ----------------------------------------------------------------------------
{
   wxString parms = wxEmptyString;
   if (IsSTK500() )
   {
       parms = wxString::Format(_T("-ve -ie%s"), fname.c_str());
   }
   #if defined(DEBUGGING)
   wxString gdblook = parms; //assign to see in gdb
   #endif
   return parms;
}


Gdb is unable to display the value of the parms string (example above) because it's a returned value. Gdb version 6.8 thru 7.0.2 will display a value of "" (in CodeBlocks) while 7.5 will sometimes crash if it attempts to access the <string>.m_pchData address.

The work around is to assign the string to a local variable that is not a return value. Gdb can then successfully examine the local variable.

Half the problem here should be owned by Codeblocks. In Gdb version 6.8-702 (and mostly 7.5), Gdb reports that the address is invalid, but CodeBlocks ignores that message and blithly attemps to display the value anyway. CodeBlocks could parse the additional gdb message and report that the variable is "unreachable" or "may be a return value".

Code Select Expand

>>>>>>cb_gdb:
> whatis parms
type = wxString
>>>>>>cb_gdb:
> output &parms
(wxString *) 0x28dc5c>>>>>>cb_gdb:
> output /c parms.m_pchData[0]@((wxStringData*)parms.m_pchData - 1)->nDataLength
Cannot access memory at address 0x28dce0
>>>>>>cb_gdb: