Visual Studio:std :: string的乱码调试手表?

时间:2021-10-11 19:49:37

When I'm debugging C++ mixed (managed/unmanaged) projects in Visual Studio 2005, I often get weird data from the debug watches, like below :
(btw, the variable i_processName is a const std::string & )

当我在Visual Studio 2005中调试C ++混合(托管/非托管)项目时,我经常会从调试监视器中获得奇怪的数据,如下所示:(顺便说一句,变量i_processName是const std :: string&)

alt text http://img175.imageshack.us/img175/3561/43419953av1.jpg

替代文字http://img175.imageshack.us/img175/3561/43419953av1.jpg

Note that the variable actually holds valid data - if i print it to stdout, the printed string is just fine, thanks for asking. The simpler types of data (e.g. ints) (usually?) get their correct values shown.

请注意,变量实际上包含有效数据 - 如果我将其打印到stdout,打印的字符串就可以了,谢谢你的询问。更简单的数据类型(例如,int)(通常是?)会显示正确的值。

Did this ever happen to you too?

这件事发生过吗?

This is a major PITA when debugging, so ... any ideas on how to make the watches show the correct data, or what's causing this?

这是调试时的主要PITA,所以......关于如何使手表显示正确数据的任何想法,或者是什么导致了这一点?

5 个解决方案

#1


Debug display of custom types (this includes the STL) depends on the file autoexp.dat located in the <install_path>\Common7\Packages\Debugger folder. Make sure that yours matches your library version and that an older version of this file hasn't been kept around (when upgrading for example).

自定义类型(包括STL)的调试显示取决于位于 \ Common7 \ Packages \ Debugger文件夹中的文件autoexp.dat。确保您的库版本与您的库版本匹配,并且该文件的旧版本尚未保留(例如,在升级时)。

Note that you can also write your own visualizers for other types, more info here and here. This is a major time saver for complex projects, well worth the (small) effort put into writing custom visualizers.

请注意,您还可以为其他类型编写自己的可视化工具,此处和此处提供更多信息。这是复杂项目的主要节省时间,非常值得(小)努力编写自定义可视化工具。

#2


Yes, i see this problem in my debuger,
in my case its connected to Unicode vs NonUnicode.

是的,我在debuger中看到了这个问题,在我的情况下,它连接到Unicode与NonUnicode。

#3


Looks like your debugging symbols are incorrect.

看起来您的调试符号不正确。

Check the modules debug window (menu: Debug>Windows). Check that modules you are debugging have "Symbols loaded." listed under the Symbol Status column. Check that the Symbol File listed is the file you think it should be. You can right click a module and get more info about how VS loaded the symbols and you can reload them as well.

检查模块调试窗口(菜单:Debug> Windows)。检查您正在调试的模块是否已“加载符号”。列在“符号状态”列下。检查列出的符号文件是否是您认为应该的文件。您可以右键单击模块并获取有关VS如何加载符号的更多信息,您也可以重新加载它们。

If you're having symbol loading problems you can set paths and other settings under Tools>Options>Debugging>Symbols.

如果您遇到符号加载问题,可以在工具>选项>调试>符号下设置路径和其他设置。

A bad call stack can cause issues like this as well. Make sure the stack doesn't have any entries like "the stack may be incorrect for this point...". Does it?

糟糕的调用堆栈也可能导致这样的问题。确保堆栈没有任何条目,例如“此时堆栈可能不正确......”。可以?

It also can be something odd with Visual Studio confusing native and manged data types in the visualizer, but I doubt it. The popup in your screen shot looks like the debugger know what the variable is.

Visual Studio中的本机和manged数据类型混淆了它也可能有些奇怪,但我对此表示怀疑。屏幕截图中的弹出窗口看起来像调试器知道变量是什么。

#4


One thought -- the STLPort implementation of std::string uses a split buffer implementation. It has a small static buffer (I want to say 14 characters) and a pointer to a char array. One of these will be invalid and the other will contain the string data, depending on the length of the stored string. If you're using STLPort or a similar implementation, your string visualizer might be looking at the wrong buffer, which happens to contain junk data.

一个想法 - std :: string的STLPort实现使用分割缓冲区实现。它有一个小的静态缓冲区(我想说14个字符)和一个指向char数组的指针。其中一个将无效,另一个将包含字符串数据,具体取决于存储的字符串的长度。如果您正在使用STLPort或类似的实现,您的字符串可视化工具可能正在查看错误的缓冲区,该缓冲区恰好包含垃圾数据。

#5


I beleive that Aardvark is probably onto the correct answer. If i remember correctly when you are compiling mixed mode, the compiler will turn as much of the C++ code it can into code that runs on the CLR, and consequently memory that is owned by the CLR. My geuss is that the debugger is confused about where the string is held - unmanaged or managed memory.

我相信Aardvark可能正确的答案。如果我在编译混合模式时记得正确,编译器会将尽可能多的C ++代码转换为在CLR上运行的代码,从而转换为CLR拥有的内存。我的geuss是调试器对字符串的保存位置感到困惑 - 非托管或托管内存。

#1


Debug display of custom types (this includes the STL) depends on the file autoexp.dat located in the <install_path>\Common7\Packages\Debugger folder. Make sure that yours matches your library version and that an older version of this file hasn't been kept around (when upgrading for example).

自定义类型(包括STL)的调试显示取决于位于 \ Common7 \ Packages \ Debugger文件夹中的文件autoexp.dat。确保您的库版本与您的库版本匹配,并且该文件的旧版本尚未保留(例如,在升级时)。

Note that you can also write your own visualizers for other types, more info here and here. This is a major time saver for complex projects, well worth the (small) effort put into writing custom visualizers.

请注意,您还可以为其他类型编写自己的可视化工具,此处和此处提供更多信息。这是复杂项目的主要节省时间,非常值得(小)努力编写自定义可视化工具。

#2


Yes, i see this problem in my debuger,
in my case its connected to Unicode vs NonUnicode.

是的,我在debuger中看到了这个问题,在我的情况下,它连接到Unicode与NonUnicode。

#3


Looks like your debugging symbols are incorrect.

看起来您的调试符号不正确。

Check the modules debug window (menu: Debug>Windows). Check that modules you are debugging have "Symbols loaded." listed under the Symbol Status column. Check that the Symbol File listed is the file you think it should be. You can right click a module and get more info about how VS loaded the symbols and you can reload them as well.

检查模块调试窗口(菜单:Debug> Windows)。检查您正在调试的模块是否已“加载符号”。列在“符号状态”列下。检查列出的符号文件是否是您认为应该的文件。您可以右键单击模块并获取有关VS如何加载符号的更多信息,您也可以重新加载它们。

If you're having symbol loading problems you can set paths and other settings under Tools>Options>Debugging>Symbols.

如果您遇到符号加载问题,可以在工具>选项>调试>符号下设置路径和其他设置。

A bad call stack can cause issues like this as well. Make sure the stack doesn't have any entries like "the stack may be incorrect for this point...". Does it?

糟糕的调用堆栈也可能导致这样的问题。确保堆栈没有任何条目,例如“此时堆栈可能不正确......”。可以?

It also can be something odd with Visual Studio confusing native and manged data types in the visualizer, but I doubt it. The popup in your screen shot looks like the debugger know what the variable is.

Visual Studio中的本机和manged数据类型混淆了它也可能有些奇怪,但我对此表示怀疑。屏幕截图中的弹出窗口看起来像调试器知道变量是什么。

#4


One thought -- the STLPort implementation of std::string uses a split buffer implementation. It has a small static buffer (I want to say 14 characters) and a pointer to a char array. One of these will be invalid and the other will contain the string data, depending on the length of the stored string. If you're using STLPort or a similar implementation, your string visualizer might be looking at the wrong buffer, which happens to contain junk data.

一个想法 - std :: string的STLPort实现使用分割缓冲区实现。它有一个小的静态缓冲区(我想说14个字符)和一个指向char数组的指针。其中一个将无效,另一个将包含字符串数据,具体取决于存储的字符串的长度。如果您正在使用STLPort或类似的实现,您的字符串可视化工具可能正在查看错误的缓冲区,该缓冲区恰好包含垃圾数据。

#5


I beleive that Aardvark is probably onto the correct answer. If i remember correctly when you are compiling mixed mode, the compiler will turn as much of the C++ code it can into code that runs on the CLR, and consequently memory that is owned by the CLR. My geuss is that the debugger is confused about where the string is held - unmanaged or managed memory.

我相信Aardvark可能正确的答案。如果我在编译混合模式时记得正确,编译器会将尽可能多的C ++代码转换为在CLR上运行的代码,从而转换为CLR拥有的内存。我的geuss是调试器对字符串的保存位置感到困惑 - 非托管或托管内存。