Author Topic: Can't see value of unicode strings while debugging  (Read 16748 times)

Offline Denis

  • Multiple posting newcomer
  • *
  • Posts: 48
Can't see value of unicode strings while debugging
« on: August 01, 2007, 05:36:07 pm »
I can't see values of unicode strings while debugging. I just see "" for wxString or something like 97 for const wchar_t* variables at watch frame or at popup hint with value. Values for variables like "const char*" or std::string (not unicode) are show correctly. How do you find out values of unicode string variables?

PS: MinGW GCC 3.4.2 + GNU gdb 6.6
PSS: Sorry for my English :-)

Offline Hitnrun

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Can't see value of unicode strings while debugging
« Reply #1 on: September 26, 2007, 06:49:19 pm »
Don't know if this can pose any trouble, but the only way I could see a wxString on the watch window, is to add the wxString variable to the watch window, right-click edit, "Edit watch", keep the type "undefined", enable the "watch as array", and set some array count (say, 20).
If the array count is bigger than the string, some garbage characters appear, don't know if this can result in a SEGV in the future.

Online eranif

  • Regular
  • ***
  • Posts: 254
Re: Can't see value of unicode strings while debugging
« Reply #2 on: September 26, 2007, 09:22:31 pm »
Hi,

I am not using C::B for debugging, but for watching wxString in unicode build, I simply type in the gdb command line:
'p str.ToAscii()' and voila!

I believe you can do this in C::B as well.

Eran

Offline Hitnrun

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Can't see value of unicode strings while debugging
« Reply #3 on: September 27, 2007, 04:51:09 pm »
Hi,

I am not using C::B for debugging, but for watching wxString in unicode build, I simply type in the gdb command line:
'p str.ToAscii()' and voila!

I believe you can do this in C::B as well.

Eran

I don't know why, but when I try to watch

str.ToAscii()

I get an error message

gdb: Kernel event for pid=XXXX tid=YYYY code=EXCEPTION_DEBUG_EVENT

does someone knows why?

Offline Denis

  • Multiple posting newcomer
  • *
  • Posts: 48
Re: Can't see value of unicode strings while debugging
« Reply #4 on: September 28, 2007, 04:41:26 pm »
This is very inconvenient ways to find out value of wxString or wchat_t* variables :( I wanna see it fast and without any problems.

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Can't see value of unicode strings while debugging
« Reply #5 on: September 28, 2007, 07:53:30 pm »
I hope you mean the following.



It works fine with me though I do get that "Kernel event for..." message. :)
Be a part of the solution, not a part of the problem.

Online eranif

  • Regular
  • ***
  • Posts: 254
Re: Can't see value of unicode strings while debugging
« Reply #6 on: September 28, 2007, 09:45:40 pm »
Quote
I don't know why, but when I try to watch

str.ToAscii()

I get an error message

gdb: Kernel event for pid=XXXX tid=YYYY code=EXCEPTION_DEBUG_EVENT

does someone knows why?

this is not an error message, these are messages that the debugger displays when setting the debugevent to on.
I guess that the debugger plugin uses this event to capture some information about the debugee process (debugee process ID maybe?)

Anyway, passing the following to the debugger, will make him shutup:
Code: [Select]
set debugevent off
Eran

Offline Denis

  • Multiple posting newcomer
  • *
  • Posts: 48
Re: Can't see value of unicode strings while debugging
« Reply #7 on: September 29, 2007, 02:01:23 pm »
However, is there fast solution to see value of unicode string?

Offline marlo

  • Single posting newcomer
  • *
  • Posts: 8
Re: Can't see value of unicode strings while debugging
« Reply #8 on: November 04, 2007, 12:33:05 pm »
I've encountered the same issue during (gdb) debugging of a wxSmith Dialog Based application within my CodeBlocks environment:
The debugger does not show contents of wxString variables.

Just to make sure that this was not related to an “old” version of CodeBlocks (snv 4237) I’ve updated my CodeBlocks environment to a more recent nightly build (snv 4564),  however the issue remains.

I've been searching the internet for half a day, but I did find a clear answer to the question if the gdb debugger within CodeBlocks is able to show wxString contents or not.

From reading threads I learned that the CodeBlocks script file "gdb_types.script" should make the (gdb) debugger aware of wxString variables.
When starting a debug session I can see that wxString is registered as new type by looking to the “Debugger Messages” window:

  Starting debugger: done
  Registered new type: wxString
  Registered new type: STL String
  Registered new type: STL Vector
  Setting breakpoints
  Debugger name and version: GNU gdb 6.3

However, if I move the mouse cursor over a wxString variable (evaluate expression under cursor), the debugger messages window tells “Cannot evaluate function -- may be inlined” and the popup window will show:
  Symbol :  <varname> (wxString)
  Address:  0x…….
  “”
If I add a wxString variable to the “Watch” Window the debugger messages window also tells “Cannot evaluate function -- may be inlined” and the Watch Window will show:
  <varname> = “”


To repeat I question I’ve seen appear in a number of threads on the internet:

- Is it possible to see the contents of wxString variables in gdb debug sessions within CodeBlocks?


If the answer is to this question is yes, are there specific boundary conditions that need to be met? For example:
- is the wxWidgets library used relevant (I’m currently using a static debug library: libwxmsw28ud.a)?
- is the project type relevant (I’m currently using a wxSmith Dialog Based project)?


Regards, Marlo

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Can't see value of unicode strings while debugging
« Reply #9 on: November 04, 2007, 02:44:52 pm »
- is the wxWidgets library used relevant (I’m currently using a static debug library: libwxmsw28ud.a)?

Yes. The linker strips code you never use from static libraries. In this case, wxString::c_str() is needed which you obviously don't use directly in your code (and so is being stripped off the resulting binary).
Evaluating wxStrings works fine with dll-based wx configurations because the aforementioned stripping does not take place.
Be patient!
This bug will be fixed soon...

Offline Ramazan Kartal

  • Multiple posting newcomer
  • *
  • Posts: 16
Re: Can't see value of unicode strings while debugging
« Reply #10 on: November 04, 2007, 05:17:27 pm »
Hi,

I think I found a solution. Could you please try the following:

1. Open the gdb_types.script file in "C:\Program Files\CodeBlocks\share\CodeBlocks\scripts". Your installation dir may be different so change the above path if necessary.

2. Find the function "Evaluate_wxString".

3. Now find the line containing:
    local result = _T("output /c ") + a_str + oper + _T("c_str()[") + start + _T("]@");

And change it to:
    local result = _T("output /c ") + a_str + oper + _T("m_pchData[") + start + _T("]@");

Note we are only changing "c_str()" to "m_pchData".

4. Now save this file, start debugging.

This worked for me, I hope it will work for you.

Regards,
Ramazan Kartal

« Last Edit: November 04, 2007, 05:19:03 pm by Ramazan Kartal »

Offline marlo

  • Single posting newcomer
  • *
  • Posts: 8
Re: Can't see value of unicode strings while debugging
« Reply #11 on: November 05, 2007, 08:43:00 am »
Mandrav,

Thanks very much for your useful feedback.
I did not see a remark about the dependency on wxWidgets libraries in earlier threads.

- is the wxWidgets library used relevant (I’m currently using a static debug library: libwxmsw28ud.a)?

Yes. The linker strips code you never use from static libraries. In this case, wxString::c_str() is needed which you obviously don't use directly in your code (and so is being stripped off the resulting binary).
Evaluating wxStrings works fine with dll-based wx configurations because the aforementioned stripping does not take place.

Considering your remark above, can I translate this into a "general guideline" for wxWidgets debugging (gdb) within the CodeBlocks environment?

  "For debugging it is strongly advised to use a Shared Debug version of wxWidgets library"


I can't recall having seen such a "guideline" in earlier readings.
In case the "guideline" above is valid then it might be useful (for other users) to document this guideline somewhere, for instance in:

http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks 


Ramazan Kartal,

I tried your suggestion and modified the "gdb_types.script" file.

I can confirm that changing the script-file has an influence on the behavior of wxString debugging within the CodeBlocks environment (with static wxWidgets debug library).

- It does not change the behavior of the "evaluate expression under cursor" CodeBlocks feature.

- It does change the behavior of a wxString variable added to the "Watch" window. If I select "Edit Watch" in the "right-click" pop-up menu of the Watch window and if I set the "Count" property to a non-zero value (even without the "watch as array" checkbox checked) I can recognize (part of) the actual string value during debugging.


Regards, Marlo

Offline Ramazan Kartal

  • Multiple posting newcomer
  • *
  • Posts: 16
Re: Can't see value of unicode strings while debugging
« Reply #12 on: November 05, 2007, 03:52:09 pm »
Dear Marlo,

Could you please do the following:

1. Open the same gdb_types.script and find the same "Evaluate_wxString" function.

2. Locate and change the following line from this:
        result = result + a_str + oper + _T("size()");

to this:
        result = result + _T("((wxStringData*)") + a_str + oper + _T("m_pchData - 1)->nDataLength");

I hope this helps. If it works ok than I will propose a patch so that it will not be owerwritten with every nightly.

Regards,
Ramazan Kartal
« Last Edit: November 05, 2007, 03:56:11 pm by Ramazan Kartal »

Offline marlo

  • Single posting newcomer
  • *
  • Posts: 8
Re: Can't see value of unicode strings while debugging
« Reply #13 on: November 05, 2007, 06:30:34 pm »
Dear Ramazan Kartal,

I've changed the two lines in the gdb_types.script file as you suggested:

    local result = _T("output /c ") + a_str + oper + _T("m_pchData[") + start + _T("]@");

        result = result + _T("((wxStringData*)") + a_str + oper + _T("m_pchData - 1)->nDataLength");

I can confirm that this solves the wxString debug issue (when using the Static wxWidgets Debug library).
Both the "evaluate expression under cursor" CodeBlocks feature and the "Watch" window watching a wxString variable now operate as desired.

Thanks a lot for your help.

Please do propose the patch so that other users can also benefit from your work in case they use a Static wxWidgets Debug Library (maybe for no good or specific reason, just like me) in their CodeBlocks environment.


I'm still intrigued by Mandrav's remark about using a Static Debug Library and code stripping by the linker.
Can we better make use of Shared Debug Libraries for debugging, or is it fair to expect same behavior during debugging when we use Static Debug Libraries?

Remark: In the past I've used the MSVC environment and I can't recall seeing different behavior when debugging projects using Static or Shared MFC libraries.


Regards, Marlo

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Can't see value of unicode strings while debugging
« Reply #14 on: November 05, 2007, 11:07:31 pm »
Quote
Remark: In the past I've used the MSVC environment and I can't recall seeing different behavior when debugging projects using Static or Shared MFC libraries.

Ramazan's solution works and is even ok for wxString. But this can't be said about other libraries, especially STL. Its implementation is vendor specific and in order to access a container's contents we must use library exposed functions (if we want to be portable), like c_str() for strings.
While wxString does indeed have a m_pchData data member (from which we can directly read the string's value), the same can't be said about STL's std::string (or other STL containers)... Each vendor has a different implementation and accessing a data member just isn't gonna cut it for us. This is the major reason why we use the c_str() function for STL string too.

MSVC on the other hand, has no such issues: everything there is provided by the same vendor and so compatibility is a given between the libraries and the environment.

Now you see why C::B's multiple compiler support is both a blessing and a curse :).

Quote
Can we better make use of Shared Debug Libraries for debugging, or is it fair to expect same behavior during debugging when we use Static Debug Libraries?

My suggestion is to use DLLs for debugging, not only for issues similar to the one you 're experiencing: if you work on an above-average sized project, DLLs will save you also because of the significantly smaller linking times.
Be patient!
This bug will be fixed soon...

Offline Ramazan Kartal

  • Multiple posting newcomer
  • *
  • Posts: 16
Re: Can't see value of unicode strings while debugging
« Reply #15 on: November 06, 2007, 12:35:43 am »
Hi,

Quote
Ramazan's solution works and is even ok for wxString. But this can't be said about other libraries, especially STL. Its implementation is vendor specific and in order to access a container's contents we must use library exposed functions (if we want to be portable), like c_str() for strings.

Then I assume it is ok to provide a patch just for wxString, because wxString internals are not implementation dependent. Am I right? Alternatively, I can write an article in wiki detailing the necessary changes in 'gdb_types.script'.

Regards,
Ramazan Kartal
 
« Last Edit: November 06, 2007, 01:00:59 am by Ramazan Kartal »

Offline marlo

  • Single posting newcomer
  • *
  • Posts: 8
Re: Can't see value of unicode strings while debugging
« Reply #16 on: November 07, 2007, 08:47:34 am »
Dear all,

In case the patch as proposed by Ramazan does not “break” debugging support for debuggers other than GDB, I strongly support that proposal.

From Mandrav’s feedback I understand that the patch is not a “general” solution and that it will not work for more complex data structures (when using the Static wxWidgets library).

However, the wxString data structure is rather fundamental in programming, just like simpler data types like int, long, bool, etc. In my opinion this should be enough to justify the patch.

The ability to debug wxString variables, independent of the wxWidgets library used (static or shared) would be very useful, especially for new users of the CodeBlocks environment. And where possible, the learning curve should not be steeper then strictly necessary.

Therefore I would like to ask the CodeBlocks development team to seriously consider implementation of the patch.



A small note on what brought me to use the Static wxWidgets library as opposed to the Shared wxWidgets library:

I'm using Biplab's wxWidgets Project wizard. Limitation of the wizard is that it will setup the CodeBlocks project to use the same wxWidgets library for both the Release Target and the Debug Target (either Static or Shared).
For Release Targets I prefer to have an executable that doesn't depend on DLL files, hence the static library.

Quite some time ago I've asked Biplab about the possibility to add support to the wxWidgets Project Wizard to support different wxWidgets library types for Release and Debug Targets (which was not easy to do). At that time my motivation for this request was only related to the required HDD space for the Static wxWidgets Debug library (about 360 MB) compared to the Shared wxWidgets Debug Library (about 75MB).

But after this useful discussion I think there is a much stronger argument for the request to change the wxWidgets Project Wizard to support different library types for Release and Debug targets: not the required HDD space (which probably affects only a small group of people) but being able to set up the CodeBlocks project for optimal debugging support.
 

Regards, Marlo.
« Last Edit: November 07, 2007, 08:52:33 am by marlo »

Offline Hitnrun

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Can't see value of unicode strings while debugging
« Reply #17 on: November 07, 2007, 09:33:46 pm »
I'm working with ICU, and my life is much more miserable than when working with wxString. The watch windows just displays "incomplete type", and says that UnicodeString is a struct not a class??

s = (const struct icu_3_6::UnicodeString &) @0xbfedeaa8: <incomplete type>

It is hell on earth trying to debug a program where you can't see the string values in a debugger.
« Last Edit: November 07, 2007, 09:36:15 pm by Hitnrun »

Offline Hitnrun

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Can't see value of unicode strings while debugging
« Reply #18 on: November 07, 2007, 10:18:48 pm »
I made the problem less worse, recompilling ICU with debug symbols. In ubuntu, ICU doesn't have a -dbg package so I had to do this:

# apt-get source icu
# cd icu-3.6
# export DEB_BUILD_OPTIONS=nostrip
# dpkg-buildpackage -rfakeroot -uc -us
# dpkg -i ../*.deb

Now I can at least see the class private fields... still not easy, but at least no impossible!

Offline Hitnrun

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Can't see value of unicode strings while debugging
« Reply #19 on: March 25, 2008, 10:22:16 pm »
I found a (hackish) way to display ICU strings, it is not pretty but works, better than nothing!

In debugger settings -> debugger initialization commands, put this text:

Quote
def pu
  set $uni = $arg0
  set $i = 0
  while (*$uni && $i++<500)
    if (*$uni < 0x80)
      printf "%c", *(char*)$uni++
    else
      echo "?"
      *(short*)$uni++
    end
  end
end

Now when you run your program, instead of using the watch window, use Debug->Send user command to debugger, and enter

pu <icu_variable_name>.fArray

and you will have a somewhat pretty print of all ASCII on your string on the debugger window.