Visual Studio 2010 Professional 中的监视值不正确

发布于 2024-12-02 10:55:29 字数 998 浏览 1 评论 0原文

我遇到了一个非常奇怪的问题,其中某些变量的监视窗口值似乎与它们的“现实世界”值不匹配。调试器似乎在太空中关闭。这是显示它的最小代码片段:

printf("%d", pNodes[nNode].nColumn); // watch shows "4"
printf("%d", nColumn); // watch shows "1"

if (pNodes[nNode].nColumn != nColumn)
  continue; // this is NOT called

因此,行为如下:

  1. 如果我向 pNodes[nNode].nColumn 添加一个监视,它会显示值 4
  2. 如果我向 nColumn 添加一个监视,它会显示值 1
  3. 如果我在监视窗口中检查表达式 pNodes[nNode].nColumn != nColumn,其计算结果为 true
  4. continue 语句被跳过!
  5. 我添加了 printf() 调用来查看发生了什么,并且 printf() 打印值 11< /code>,这似乎与代码“流动”的方式一致(即它if 语句中调用 continue

我什至可以检查内存 &pNodes(nNode].nColumn,并且内存显示监视窗口向我显示的“不正确”值。因此,调试器似乎与实际程序数据完全“断开”我正在运行调试构建优化,我还检查了 pNodes 不对应于某些全局变量或其他更高范围的变量 - 似乎只有一个本地版本

。我!我什至不知道下一步该去哪里尝试解决问题如果您有任何想法,我很乐意听到他们,

谢谢!

I'm having a really bizarre problem wherein the watch window values for some variables don't seem to match their "real world" values. The debugger just appears to be off in space. Here's the tiniest code snippet that shows it:

printf("%d", pNodes[nNode].nColumn); // watch shows "4"
printf("%d", nColumn); // watch shows "1"

if (pNodes[nNode].nColumn != nColumn)
  continue; // this is NOT called

So here's the behaviour:

  1. If I add a watch to pNodes[nNode].nColumn, it shows a value of 4.
  2. If I add a watch to nColumn, it shows a value of 1.
  3. If I check the expression pNodes[nNode].nColumn != nColumn in the watch window, it evaluates to true.
  4. The continue statement is skipped!
  5. I added the printf() calls to see what was going on, and the printf() prints the values 1 and 1, which seems to agree with the way the code "flows" (i.e. that it does not call the continue inside the if statement.

I can even check the memory at &pNodes(nNode].nColumn, and the memory shows the "incorrect" values that the watch window is showing me. So it seems like the debugger is getting completely "disconnected" from the actual program data or something. I'm running a debug build optimizations are turned off. I've also checked that pNodes does not correspond to some global variable or other variable higher in scope -- it seems there's only a local version.

This is completely baffling to me! I'm not even sure where to go next to try to figure out the problem. If you have any ideas whatsoever, I'd love to hear them!

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

金橙橙 2024-12-09 10:55:29

所以我想我已经解决了这个问题:罪魁祸首是结构成员对齐。我有很多项目混合在一起,其中一些项目在项目中对该字段具有不同的值。我删除了所有这些设置,让 VS 选择默认值,问题就消失了。

在某些项目中,适用的值在 4 字节之间,在某些项目中,适用值在 默认 之间,而在其他项目中,则完全为空。该值位于配置属性/C/C++/代码生成/结构成员对齐下。同样,我最终只是完全删除了项目的值。我认为这是在过去的某个时候在项目上设置的,以处理某种跨平台问题,但至少它对于我现在正在做的工作是固定的!

感谢您的帮助!

So I think I've cracked the case: The culprit was Struct Member Alignment. I had a bunch of projects mixed together and some of them had varying values for this field inside the projects. I removed the settings on all of them to just let VS pick the defaults and the problem has disappeared.

The applicable value was between 4 bytes in some of the projects, Default in some of the projects, and empty altogether in others. The value is under Configuration Properties/ C/C++ / Code Generation / Struct Member Alignment. Again, I ended up just deleting the values altogether for the projects. I think this was set on the projects at some point in the past to deal with some kind of cross-platform issue, but at least it's fixed for the work I'm doing now!

Thanks for all of your help!

执手闯天涯 2024-12-09 10:55:29

如果使用不在范围内的变量设置监视,这就是我在 Visual Studio 中经常看到的行为。它确实应该说“<不在范围内>”或者更有用的东西。

如果您单步执行这些代码行并且仍然看到那些幽灵般的值,我不知道:您确定它是调试版本吗?

If watches are set using variables not in scope, that is the sort of behavior I see all the time with Visual Studio. It really should say "<not in scope>" or something more useful.

If you are stepping through these lines of code and you still see those ghostly values, I don't know: are you sure it is a debug build?

总以为 2024-12-09 10:55:29

Visual Studio 2010 调试器在跟踪监视变量内存位置时存在问题。有时它会严重误导您,因为 VS2010 没有向您显示您认为它正在向您显示的变量。

例如,如果您在函数中重复使用变量名称,则监视窗口中应显示的内存位置会随着执行范围的变化而变化:

for (int i=0; i<10; i++) {
   i=i+1; // do something, what isn't important
}

int i;
for (i=0; i<5; i++) {
  i=i+1; // do something 
}

printf("i=%d\n", i);

现在将变量i放入监视窗口中。

显然,监视窗口中显示哪个 i(或值)很重要。
如果运行该程序,您将看到当它进入 for 循环时,手表会跟踪 for 循环的 i 变量。当它退出 for 循环,然后使用另一个同名变量点击下面的代码时,监视窗口不会跟踪该变量的内存。

您将看到监视窗口仍然声明 i 是 10,即使在第二个循环中 i 现在是 0,1,2,...,并且在第二个循环之后 i 实际上是 6,但监视窗口仍然声明 i 是 10。

监视窗口应该做什么?我认为,它应该始终向您显示具有该监视名称的变量的值,即在范围内,因为语言规则告诉您在任何给定时间只有这些变量之一在范围内。

这是调试器的监视窗口功能中的一个错误(VS2010 似乎很便宜地只是找到函数中与您在监视中指定的名称相匹配的第一个变量,并顽强地监视该内存空间,而不管代码中可能还有什么,即使具有相同名称的新变量已经接管了范围(此时监视窗口现在对您撒谎!)

Visual Studio 2010 debugger has issues with tracking watch variable memory locations. Sometimes it will mislead you badly because VS2010 is NOT showing you the variable you think it is showing you.

For example, if you re-use a variable name within a function, so which memory location should be displayed in the watch window CHANGES as the execution scope changes:

for (int i=0; i<10; i++) {
   i=i+1; // do something, what isn't important
}

int i;
for (i=0; i<5; i++) {
  i=i+1; // do something 
}

printf("i=%d\n", i);

Now put the variable i in the watch window.

Obviously, which i (or value) is displayed in the watch window matters.
If you run the program, you will see that as it enters the for-loop the watch tracks the i variable of the for loop. When it exits the for loop, and then hits the code below with the other variable with the same name the watch window isn't tracking that variable's memory.

You will see the watch window still declaring i is 10, even though in the 2nd loop i is now 0,1,2,... and after the 2nd loop i is actually 6, but the watch window still declares i is 10.

And what should the watch window do? I would argue, it should always show you the value of the variable with that watch name, that is in scope, as the language rules tell you only one of those variables is in scope at any given time.

Its a bug in the debugger's watch window functionality here (VS2010 seems to cheaply just find the first variable in the function that matches the name you gave it in the watch, and doggedly watch THAT memory space, regardless of what else may be in the code, even if a new variable with the same name has taken over scope (at which point the watch window is now lying to you!)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文