什么时候除以零不是除以零?调试器中的一个难题(静态变量问题)

When is a divide by zero not a divide by zero? A puzzle in the debugger (static variable issues)

我很困惑,我认为我的调试器在骗我。我的代码中有以下循环:

MyClass::UploadFile(CString strFile)
{
  ...
  static DWORD dwLockWaitTime = EngKey::GetDWORD(DNENG_SERVER_UPLOAD_LOCK_WAIT_TIME, DNENG_SERVER_UPLOAD_LOCK_WAIT_TIME_DEFAULT);
  static DWORD dwLockPollInterval = EngKey::GetDWORD(DNENG_SERVER_UPLOAD_LOCK_POLL_INTERVAL, DNENG_SERVER_UPLOAD_LOCK_POLL_INTERVAL_DEFAULT);

  LONGLONG llReturnedOffset(0LL);
  BOOL bLocked(FALSE);
  for (DWORD sanity = 0; (sanity == 0 || status == RESUMABLE_FILE_LOCKED) && sanity < (dwLockWaitTime / dwLockPollInterval); sanity++) 
    {
      ...

这个循环在我的程序过程中已经执行了数百次,并且两个静态变量在代码中的任何地方都没有改变,它们在静态初始化和读取时只写入一次循环条件和另一个地方。由于它们是从 Windows 注册表中读取的用户设置,因此它们几乎总是具有 dwLockWaitTime = 60 和 dwLockPollInterval = 5 的常量值。因此循环始终执行 60 / 5。

在极少数情况下,我得到一个故障转储,显示这行代码引发了 division by zero 错误。我检查了 WinDbg 所说的内容,它显示:

FAULTING_IP: 
procname!CServerAgent::ResumableUpload+54a [serveragent.cpp @ 725]
00000001`3f72d74a f73570151c00    div     eax,dword ptr [proc!dwLockPollInterval (00000001`3f8eecc0)]

EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 000000013f72d74a (proc!CServerAgent::ResumableUpload+0x000000000000054a)
   ExceptionCode: c0000094 (Integer divide-by-zero)
  ExceptionFlags: 00000000
NumberParameters: 0

ERROR_CODE: (NTSTATUS) 0xc0000094 - {EXCEPTION}  Integer division by zero.

我检查了汇编代码,它显示崩溃发生在这条 div 指令上。

00000001`3f72d744 8b0572151c00    mov     eax,dword ptr [dwLockWaitTime (00000001`3f8eecbc)]
00000001`3f72d74a f73570151c00    div     eax,dword ptr [dwLockPollInterval (00000001`3f8eecc0)]

因此,如您所见,000000013f8eecbc 处的值已移至 eax,然后 eax 被 divided 处的值 000000013f8eecc0.

你问的这两个值是多少?

0:048> dd 00000001`3f8eecbc
00000001`3f8eecbc  0000003c 00000005 00000001 00000000
00000001`3f8eeccc  00000000 00000002 00000000 00000000
00000001`3f8eecdc  00000000 7fffffff a9ad25cf 7fffffff
00000001`3f8eecec  a9ad25cf 00000000 00000000 00000000
00000001`3f8eecfc  00000000 00000000 00000000 00000000
00000001`3f8eed0c  00000000 00000000 00000000 00000000
00000001`3f8eed1c  00000000 00000000 00000000 00000000
00000001`3f8eed2c  00000000 00000000 00000000 00000000
0:048> dd 000000013f8eecc0
00000001`3f8eecc0  00000005 00000001 00000000 00000000
00000001`3f8eecd0  00000002 00000000 00000000 00000000
00000001`3f8eece0  7fffffff a9ad25cf 7fffffff a9ad25cf
00000001`3f8eecf0  00000000 00000000 00000000 00000000
00000001`3f8eed00  00000000 00000000 00000000 00000000
00000001`3f8eed10  00000000 00000000 00000000 00000000
00000001`3f8eed20  00000000 00000000 00000000 00000000
00000001`3f8eed30  00000000 00000000 00000000 00000000

常量 605 完全符合我的预期。那么 divide 在哪里呢???我的调试器在撒谎吗?当然 divide 为零是由硬件抛出的,所以它不会犯错吗?如果它是我代码中不同位置的 divide 零,调试器将在这个地方显示指令指针的几率是多少?我承认,我被难住了..

问题可能与多线程有关。

  1. 一个线程进入函数
  2. 检查隐藏的 "is_initialized" 静态变量以查看是否已执行初始化
  3. var 为 0,因此它将变量设置为 1 并继续读取注册表
  4. 此时另一个线程进入函数
  5. 第二个线程认为变量已经初始化并跳过初始化代码
  6. 除法在分母仍为0时进行(第一个线程还在读注册表)
  7. 程序崩溃,但同时第一个线程完成执行,设置您在转储中看到的变量。
  8. 你会失眠,想着不可能的事情是如何发生的

由于代码是成员函数的一部分,并且您从多个线程调用此函数,因此如果使用不符合 C++ 11 标准的编译器,static 变量不是线程安全的.因此,在初始化这两个静态变量时,您可能会遇到数据竞争。

对于符合 C++ 11 标准的编译器,静态变量现在保证由第一个线程初始化,而后续线程等待静态变量初始化。

对于Visual Studio 2010及以下版本,不保证静态局部变量是线程安全的,因为这些编译器符合C++ 03和C++ 98标准。

对于 Visual Studio 2013,我不确定 C++ 11 在静态局部初始化方面的支持级别。因此,对于 Visual Studio 2013,您可能必须使用适当的同步来确保正确初始化静态局部变量。

对于 Visual Studio 2015,此项目已得到解决,并且已完全实现正确的静态本地初始化,因此您当前拥有的代码应该适用于 VS 2015 及更高版本。


编辑:对于 Visual Studio 2013,未实现静态局部线程安全初始化 ("Magic Statics"),as described here

因此,我们可以谨慎验证原来问题的原因是静态本地初始化问题和线程问题。所以解决方案(如果你想坚持使用 VS 2013)是使用适当的同步,或者重新设计你的应用程序以便不再需要静态变量。