2

仅当我在“免费”（发布）中使用 WinDDK nmake 编译器构建时才会出现此错误，该编译器执行优化。我无法在“已检查”构建或使用 VS 编译中重现此问题。

这是我的代码中发生的事情的伪代码：

main()
{
   //variable init and other code
    fprintf(log, "pre nullValue: %lu\n", NULL);  //printf added for debugging
   otherFunc();
   funcWithError(str1, str2, NULL);
    fprintf(log, "post nullValue: %lu\n", NULL); 
    fprintf(log, "post2 nullValue: %lu, %lu, %lu\n", NULL, 0, NULL);
}

BOOL otherFunc()
{
   //variable init and other code
   callToDll();
    //...doing stuff
   libusb_usb_open(var1);    //If I remove this line there is no problem!!
    //...doing more stuff
}

BOOL funcWithError(char* s1, char* s2, FUNC_PTR fp)
{
    fprintf(log, "inFunc nullValue: %lu, %lu\n", NULL, fp);
   if(fp != NULL)
      return FALSE;        //This line is being executed erroneously!!
}

日志输出：
pre nullValue: 0
inFunc nullValue: 0, 251208
post nullValue: 251208
post2 nullValue: 251208, 251208, 251208
注意：每次程序运行时重复出现的数字（251208）都是不同的数字

只需更改一行即可修复/导致它。这是libusb usb_open调用。

  1. 最终我的问题是弄清楚如何解决这个问题（我无法避免那个电话）
  2. 但只是在堆栈/内存管理级别上，怎么可能让 NULL 不为零并且将文字值 '0' 打印为非零？

让我知道其他信息可能会有所帮助...

4

2 回答 2

3

不是一个完全灌篮。但是堆栈很可能会变得不平衡。在调试器中（是的，您可以调试发布版本），在调用前后检查 ESP 寄存器的值。应该是一样的。如果函数的调用约定错误，则不会。就像 __stdcall 与 __cdecl。

当您使用 nmake.exe 构建程序时，这可以很好地隐藏自己，很容易忘记在调试构建中打开 /RTCs 选项，因此会发出堆栈检查代码。ESP 寄存器倾向于在函数返回时自行恢复。直到您构建发布版本，其中函数被内联并且 EBP 的使用被优化掉，所以 ESP 不再自我恢复。

于 2011-05-07T00:56:50.920 回答
0

更新：所以，我终于让 windbg 闯入 dll 并检查一些东西。正如我最初怀疑和 Hans 指出的那样，这是由不匹配的调用约定引起的堆栈损坏。

使它仅在发布版本中可见的原因是编译器优化了 0/Null 值以使用 ebx 寄存器值而不是传递 0。在 OtherFunc() 中，优化使用 ebx 来存储其他几个值，然后调用 Usb_Open () 破坏了堆栈，然后当 OtherFunc() 尝试弹出堆栈以恢复原始 ebx 值时，它恢复了垃圾而不是“0”。因此，回到 main() 中，每个对 NULL 的优化引用都在使用这个垃圾值。

注意：其他 dll 调用没有破坏堆栈的原因是因为它们是无参数的。

所以总而言之，答案是：

  1. 使用正确的约定调用 libusb（libusb 使用 __cdecl 调用约定，NMAKE 默认使用 __stdcall）
  2. Even though NULL and '0' are hard coded in the source code, the compiler can optimize to use a register rather than pass a value, and registers are subject to corruption from bad code.
于 2011-05-10T21:02:04.040 回答