我正在使用VS2013构建针对2010编译器的Windows 7（我们已经迁移了我们的开发环境，但不是所有项目）。程序状态和调试器不同意
我真的不知道如何表征这个问题，或者我会谷歌它。我有一个指向字节缓冲区的指针，它是我们的有线协议（代码基础早于Google及其协议缓冲区）。我们有标题，表示一个id和一个类型;将指针转换为适当的类型，您可以访问数据，并且数据是动态大小的，例如字符串字段，长度。这一切都不应该是令人惊讶的，如果不是有点老派...
但我所看到的是我有代码检查字段ID - 它不应该是零。但条件是打击，当我检查调试器中的元素时，缓冲区内容和指针位置都是正确的 - 该字段不为零。
所以我的问题给你：
1）如何将能够更好地表达这个问题，所以我可以谷歌？
2）你以前见过这个吗？有任何想法吗？
找到。一个很难看的分号终止了这个条件;我每次都碰到身体。更好的指针算术纠正了进一步的堆损坏，“realloc（buff，size）”应该是“buff = realloc（buff，size）”。
这是一个长镜头，但是，当项目不正确时我已经看到它。您可以尝试清理解决方案并重新构建它。
不幸的是，这是定期行使。我一直在寻找这个好几天。 –
有几个（的组合）的问题可以像这样呈现。
在生产设置中失败的代码，但在调试时逐步完成的代码。在这种情况下失败的真正罪魁祸首，通常是一些其他不相关的代码滥用指针（并覆盖它不应该的内存）。事情是，开发人员得到一个错误报告，然后用调试器遍历代码。除了使用调试器的事实之外，另一个区别是生产代码是用某种形式的“完全”优化编译的，而代码是在没有优化（并且具有符号输出）的情况下重新编译以供调试器使用。这改变了程序中数据（甚至代码）的内存布局。有问题的代码仍在骚扰指针，但内存中的其他内容正在被覆盖。这意味着调试时症状消失。对此的唯一解决方法是仔细检查在报告崩溃之前执行的其他代码。
另一种可能性是构建过程已经搞乱了，并且包含了陈旧旧bug的函数的过时实现。尝试做一个“干净”和“建立”。
第三种可能性是代码在调试和生产设置中执行不同的操作。例如，在#ifdef DEBUG ... #endif中包含的代码仅在调试时才有效。这种代码通常用于产生“调试输出”。它也会导致程序中内存布局的改变，从而影响指针误用的症状。
在你描述的场景中，类型转换也可能是无效的。当将char指针投射到指向X的指针时，隐含地认为X具有特定大小是相当常见的。问题是（除了char类型）所有类型的大小都是实现定义的。当代码使用不同的编译器重新编译时，这种不匹配（例如程序编写流和解释它假定差异大小的程序）是潜在的罪魁祸首。 [这并不能解释在调试和生产环境中出现和消失的症状，但是可以看出一个潜在的原因]。
要调试生产代码，开发人员可以启动生产代码，附加调试器，添加所需的任何中断点，然后让代码运行，直到出现问题。通过这种方式，可以调试具有优化的生产代码。 – StarPilot
这是事实，Starpilot。但是，通常，在使用调试器时，开发人员通常使用为调试而构建的代码，因为有用的信息可用于生产可执行文件中不存在的调试版本。而且，“事情变得有趣”的地方总是在触发问题的代码之后的某个执行点。开发人员经常等到事情“变得有趣”并且从那里开始前进，没有意识到他们需要向真正的罪犯回击。 – Peter
此代码尚未达到生产，我没有在发布版本中尝试过。协议缓冲区代码大于30岁，因此这是我要调查的最后一个罪魁祸首。我同意这可能是一些内存布局问题。 –
没有代码，没有cookie。 – leppie
您正在使用构建于vs2010上的obj/exe文件在vs2013中进行调试？ –
观察变量。在GDB中，您可以简单地“观看”。你会看到有人正在改变价值。 – CyberGuy