User forums > Using Code::Blocks

Debugging and wxWidgets

<< < (2/2)

mmccarty12:

--- Quote from: oBFusCATed on May 27, 2010, 03:14:53 pm ---Another thing you can do is to try gdb from the command line... or DDD, kdbg or something similar.

--- End quote ---

{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:

--- Quote from: oBFusCATed on May 27, 2010, 04:47:46 pm ---mmccarty12: When you submit the bug, please tell me the id/number, so I can try it on the debugger branch.

--- End quote ---

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: ---> output test
{
  <wxStringBase> = {
    m_pchData = 0x6916d8 L"\x69d9c8"
  }, <No data fields>}>>>>>>cb_gdb:

--- End code ---

Can you provide a simple test project?

Pecan:

--- Quote from: mmccarty12 on May 26, 2010, 04:19:29 pm ---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


--- End quote ---

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: ---// ----------------------------------------------------------------------------
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;
}

--- End code ---


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

--- End code ---

Navigation

[0] Message Index

[*] Previous page