7

我无法找到导致 Win32 应用程序挂起的原因。该软件在一个紧密的循环中将一些数据呈现给 OpenGL 视觉对象：

std::vector<uint8_t> indices;
glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(2, GL_DOUBLE, 0, vertexDataBuffer);
while (...) {
    // get index type (1, 2, 4) and index count
    indices.resize(indexType * count);

    // get indices into "indices" buffer
    getIndices(indices.data(), indices.size()); //< seems to hang here!

    // draw (I'm using the correct parameters)
    glDrawElements(GL_TRIANGLES_*, count, GL_UNSIGNED_*);
}
glDisableClientState(GL_VERTEX_ARRAY);

该代码使用 VC11 Update 1 (CTP 3) 编译。在运行优化的二进制文件时，它会getIndices()在几个循环之后挂在对（更多关于这一点的）的调用中。我已经有了...

  • 三重验证所有缓冲区，甚至附加 CRC 以确保我没有任何缓冲区溢出
  • 在循环内添加了对HeapValidate()的调用，以确保堆没有损坏
  • 使用 ApplicationVerifier
  • 使用GFlags 和 PageHeap启用堆分配监视。
  • 应用程序锁定时闯入 WinDbg

我没有发现访问分配缓冲区的代码有任何问题，也没有发现任何堆损坏。但是，如果我禁用低碎片堆，问题就会消失。indices如果我为缓冲区使用单独的（低碎片）堆，它也会消失。

无论如何，这是导致死锁的堆栈跟踪：

0:000> kb
ChildEBP RetAddr  Args to Child              
0034e328 77b039c3 00000000 0034e350 00000000 ntdll!ZwWaitForKeyedEvent+0x15
0034e394 77b062bc 77b94724 080d36a8 0034e464 ntdll!RtlAcquireSRWLockExclusive+0x12e
0034e3c0 77aeb652 0034e464 0034e4b4 00000000 ntdll!RtlpCallVectoredHandlers+0x58
0034e3d4 77aeb314 0034e464 0034e4b4 77b94724 ntdll!RtlCallVectoredExceptionHandlers+0x12
0034e44c 77aa0133 0034e464 0034e4b4 0034e464 ntdll!RtlDispatchException+0x19
0034e44c 77b062c5 0034e464 0034e4b4 0034e464 ntdll!KiUserExceptionDispatcher+0xf
0034e7bc 77aeb652 0034e860 0034e8b0 00000000 ntdll!RtlpCallVectoredHandlers+0x61
0034e7d0 77aeb314 0034e860 0034e8b0 0034ec28 ntdll!RtlCallVectoredExceptionHandlers+0x12
0034e848 77aa0133 0034e860 0034e8b0 0034e860 ntdll!RtlDispatchException+0x19
0034e848 1c43c666 0034e860 0034e8b0 0034e860 ntdll!KiUserExceptionDispatcher+0xf
0034ebe8 1c43c4e5 0034ec28 080d35d0 080d35d6 lcdb4!lc::db::PackedIndices::unpackIndices<unsigned char>+0x86
0034ec14 1c45922d 0034ec28 080d35d0 00000006 lcdb4!lc::db::PackedIndices::unpack+0xb5
...
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx getIndices

为了完整起见，我将 的代码（lc::db::PackedIndices::unpackIndices()包括为调试添加的所有代码）发布到http://ideone.com/sVVXX7。

触发调用的代码KiUserExceptionDispatcher是(*p++) = static_cast<T>(index);( mov dword ptr [esp+10h],eax)。

我似乎无法弄清楚发生了什么。似乎抛出了异常，但没有调用我的异常处理程序。应用程序只是挂起。我检查了任何死锁的关键部分 ( !lock)，但没有找到。此外，我不明白为什么应该引发异常，因为内存位置都是有效的。谁能给我一些提示？

更新

我试图找到抛出的异常类型：

0:000> s -d esp L1000 1003f
0028ebdc  0001003f 00000000 00000000 00000000  ?...............
0028efd8  0001003f 00000000 00000000 00000000  ?...............
0:000> .cxr 0028ebdc
eax=77b94724 ebx=0804be30 ecx=00000002 edx=00000004 esi=77b94724 edi=0804be28
eip=77b062c5 esp=0028eec4 ebp=0028eee4 iopl=0         nv up ei ng nz na pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010287
ntdll!RtlpCallVectoredHandlers+0x61:
77b062c5 ff03            inc     dword ptr [ebx]      ds:002b:0804be30=00000001
0:000> .cxr 0028efd8
eax=0000003b ebx=00000001 ecx=0804bd98 edx=0028f340 esi=0028f340 edi=04b77580
eip=1c43c296 esp=0028f2c0 ebp=0028f2fc iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
lcdb4!lc::db::PackedIndices::unpackIndices<unsigned char>+0x36:
1c43c296 8801            mov     byte ptr [ecx],al          ds:002b:0804bd98=3e
4

3 回答 3

2

堆栈跟踪讲述了这个故事。您的程序正在崩溃，这很可能是访问冲突异常，是 C++ 代码的典型故障模式，通常由堆损坏触发。然后，Windows 会尝试调用异常过滤器来查找愿意处理异常的任何代码。首先是 AddVectoredExceptionHandler() 安装的处理程序。当其中一个处理程序反过来导致崩溃时，它必须使用锁来防止重新进入。

这就是降压停止的地方。堆栈跟踪中的确切原因尚不清楚。这可能是因为另一个线程也因堆损坏而倒下，正忙于处理异常并获得了锁。使用 Debug + Windows + Threads 来查看它们。但更有可能的是，进程状态如此混乱，以至于锁对象本身也被破坏了。不太可能，但确实会发生。

是的，关闭低碎片堆有隐藏堆损坏的诀窍。内存布局将非常不同，因此导致损坏的任何代码现在都可能破坏了一些无辜的东西。这当然不是解决方案。

Debug + Exception，勾选“Win32 Exceptions”的Thrown复选框。抛出异常时，调试器现在将停止。至少你会知道抛出了什么异常。最终，您确实需要找出堆损坏发生的位置。它永远不会位于崩溃的代码中，祝你调试好运。

于 2012-11-02T12:04:50.217 回答
2

线程挂起，等待属于 OS 异常处理代码的 SRW（细长读写锁）上的排他锁。该异常是由您的代码引起的。可以使用以下堆栈帧找到确切的异常及其详细信息。0034e848 77aa0133 0034e860 0034e8b0 0034e860 ntdll!RtlDispatchException+0x19 - RtlDispatchException的参数是指向EXCEPTION_RECORD的指针。所以如果你输入.exr 0034e860你可以看到异常记录。从异常记录中，您将知道对哪个地址的访问导致异常（如果异常是访问冲突异常）。

因为，在这些步骤之后，您发现访问冲突是由于写入您在堆上正确分配的地址而发生的 - 您可以通过命令!address找到包含该地址的虚拟页面的保护属性虚拟地址”

正如您发现页面保护属性已在这些堆地址上更改为（通过某些代码）PAGE_READONLY并且在看到其他线程的调用堆栈之后，我有以下猜想，我认为这可能会帮助您找到根本原因。

我猜测 Windows 堆管理器会在引发异常以指示堆损坏之前更改页面属性。ole 堆中似乎也存在一些损坏 - 来自您显示的其他线程的调用堆栈。问题的根源可能是破坏堆的代码 - 堆随后发现并引发异常，随后操作系统的异常机制实现代码启动并在它能够调用之前挂在 SWR 锁上您或其他库代码中的异常处理程序。在此之后，您的代码中的另一个无知线程正确地接触了堆内存，由于它已经发现的损坏，堆已经受到保护，导致异常并使异常机制代码启动并落入同一个僵局。

于 2012-11-04T05:49:05.570 回答
1

如果您使用的是 ATI 显卡（带有 ATI 驱动程序），这是一个已知问题，您不能泄漏任何状态，否则以后会发生内存损坏。

尝试禁用所有可以禁用的状态 (glDisableClientState)，使用 APITrace 找出您忘记了哪个状态。

在图形驱动程序中测试内存损坏的一种简单方法是在另一个板/驱动程序上进行测试，或者强制软件渲染。

于 2012-11-02T11:20:49.787 回答