我在Windows 7上使用VS2013构建对抗2010编译器（我们已经迁移了我们的开发环境，但不是所有项目）。
我真的不知道如何描述这个问题，或者我会谷歌。我有一个指向字节缓冲区的指针，它是我们的有线协议（代码库早于Google及其协议缓冲区）。我们有标题表示id和类型;将指针转换为适当的类型，您可以访问数据，如果数据是动态的，如字符串字段，长度。如果不是有点旧学校，这一切都不应该令人惊讶......
但我所看到的是我有代码检查字段ID - 它永远不应该为零。但条件是命中，当我检查调试器中的元素时，缓冲区内容和指针位置都是正确的 - 字段是非零的。
所以我向你提问：
1）我怎样才能更好地表达这个问题，以便我可以谷歌呢？
2）你以前见过这个吗？有什么想法吗？
答案 0 :(得分：2)
这是一个很长的镜头，但是，当项目没有正确构建时，我已经看到了它。您可以尝试清理解决方案并重新构建它。
答案 1 :(得分：1)
可能存在一些（组合）问题。
在生产设置中失败的代码，但在调试时单步执行则不然。在这种情况下失败的真正罪魁祸首是，大多数情况下，一些其他不相关的代码滥用指针（并覆盖它不应该的内存）。问题是，开发人员获取错误报告，然后使用调试器逐步执行代码。除了使用调试器的事实之外，另一个区别是生产代码是用某种形式的＆＃34; full＆＃34;编译的。优化，同时重新编译代码而不进行优化（并使用符号输出）供调试器使用。这改变了程序中数据（甚至代码）的内存布局。违规代码仍在骚扰其指针，但内存中的其他内容正在被覆盖。这意味着调试时症状会消失。唯一的解决方法是仔细检查在报告崩溃之前执行的其他代码。
另一种可能性是构建过程已经搞砸了，并且包括过时的函数实现，这些函数表现出旧的bug。尝试做一个＆＃34; make clean＆＃34;和＃34; make build＆＃34;。
第三种可能性是代码在调试和制作设置中做了不同的事情。例如，代码包含在#ifdef DEBUG ... #endif中，仅在调试时才有效。这样的代码通常用于产品调试输出＆＃34;。它还会导致程序中内存布局的改变，从而影响指针滥用的症状。
在您描述的场景中，类型转换也可能无效。将char指针强制转换为指向X的指针时，通常会隐式假设X具有特定大小。问题是（除char类型之外）所有类型的大小都是实现定义的。当使用不同的编译器重建代码时，这种不匹配（例如程序编写流和程序解释它假定差异大小）是一个潜在的罪魁祸首。 [这并不能解释在调试与生产设置中出现和消失的症状，但这是一个可能的原因。]
答案 2 :(得分：0)
实测值。一个难以看见的分号终止了这个条件;我每次都在打击状态。更好的指针算法纠正了进一步的堆损坏，“realloc（buff，size）”应该是“buff = realloc（buff，size）”。