Author Topic: Debugging and wxWidgets  (Read 7669 times)

Offline mmccarty12

  • Multiple posting newcomer
  • *
  • Posts: 28
Debugging and wxWidgets
« 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

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Debugging and wxWidgets
« Reply #1 on: May 26, 2010, 07:05:22 pm »
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)?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline mmccarty12

  • Multiple posting newcomer
  • *
  • Posts: 28
Re: Debugging and wxWidgets
« Reply #2 on: May 27, 2010, 02:20:32 pm »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Debugging and wxWidgets
« Reply #3 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.

You can inspect the debuggers log for some problems ( settings -> compiler & debugger -> debugger -> show debugger's debug log)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Debugging and wxWidgets
« Reply #4 on: May 27, 2010, 03:35:37 pm »
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.

Offline mmccarty12

  • Multiple posting newcomer
  • *
  • Posts: 28
Re: Debugging and wxWidgets
« Reply #5 on: May 27, 2010, 03:55:20 pm »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Debugging and wxWidgets
« Reply #6 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline mmccarty12

  • Multiple posting newcomer
  • *
  • Posts: 28
Re: Debugging and wxWidgets
« Reply #7 on: May 27, 2010, 05:47:54 pm »
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

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Debugging and wxWidgets
« Reply #8 on: May 28, 2010, 12:30:31 am »
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:

Can you provide a simple test project?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Debugging and wxWidgets
« Reply #9 on: June 18, 2010, 01:54:53 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


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


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:
« Last Edit: June 18, 2010, 02:19:45 pm by Pecan »