Windbg 임계 영역의 BUG 추적

최근에 한 프로그램의 인터페이스 카드 사망 문제를 추적했는데 이 카드 사망은 간혹 발생한다. 한 번dump를 잡은 후 windbg로 분석을 불러오고 함수 호출 창고를 출력한 후에 임계 구역의 자물쇠가 사라진 것을 한눈에 알 수 있다.
코드:

0:000:x86> kb
ChildEBP RetAddr  Args to Child              
0032dd0c 779ed993 00000710 00000000 00000000 ntdll_779b0000!NtWaitForSingleObject+0x15
0032dd70 779ed877 00000000 00000000 024023f0 ntdll_779b0000!RtlpWaitOnCriticalSection+0x13e
0032dd98 58a2fac3 02404c50 856fd57e 024023f0 ntdll_779b0000!RtlEnterCriticalSection+0x150
0032dffc 58a0d4d7 856fea8a 00000000 001c41a0 SogouSoftware_589d0000!CDownloadListUI::UpdateDownloadListUI+0x43

임계 영역에 대한 정보를 출력하려면 다음과 같이 하십시오.
코드:

0:000:x86> !cs 02404c50
-----------------------------------------
Critical section   = 0x0000000002404c50 (+0x2404C50)
DebugInfo          = 0x0000000000611e08
LOCKED
LockCount          = 0xFFFFFFFF
WaiterWoken        = Yes
OwningThread       = 0x0000000000000710
RecursionCount     = 0x1A38
LockSemaphore      = 0x2433B08
SpinCount          = 0x0000000000000000

Windbg 지시는 0x710호 라인이 이 임계 구역을 차지하고 있음을 나타냅니다. 그래서 0x710호 라인이 그 라인인 것을 보았는데, 그 결과 오류가 발생했습니다. 일반적으로 이런 경우 라인이 종료되었거나 종료되었습니다.
코드:

0:000:x86> ~~[710]
                 ^ Illegal thread error in '~~[710]'

임계 영역의 잠금 위치 부분 코드는 다음과 같습니다.
코드:

void CDownloadListUI::UpdateDownloadListUI()
{
  m_vctLock.Lock();
  vector<int> vecDeleteItems(GetCount());  // record index to be delete
  std::iota(vecDeleteItems.begin(), vecDeleteItems.end(), 0);
  ......
  m_vctLock.UnLock();
}

  m_vctLock은 ATL의 임계 구역을 간단하게 봉인하는 클래스로 동료가 m 에 대해 자세히vctLock의 모든 잠금 위치를 검사한 결과 메인 라인을 제외한 다른 작업 라인만 사용할 수 있음을 발견했습니다. windbg로 작업 라인을 바꾸었는데 종료되지 않았습니다. 라인 ID도 0x710이 되지 않았습니다. 설마 또 Windbg에 의해 흔들렸을까요?임계 영역의 데이터 구조를 인쇄해 보십시오.
코드:

0:000:x86> dt _RTL_CRITICAL_SECTION 02404c50
DuiLib!_RTL_CRITICAL_SECTION
   +0x000 DebugInfo        : 0x00611e08 _RTL_CRITICAL_SECTION_DEBUG
   +0x004 LockCount        : 0n-6
   +0x008 RecursionCount   : 0n1
   +0x00c OwningThread     : 0x00001a38 Void
   +0x010 LockSemaphore    : 0x00000710 Void
   +0x014 SpinCount        : 0

여기에 표시된 소유자 스레드 번호가 위와 일치하지 않는 것을 발견했습니다. 그 스레드를 시험해 보십시오.
코드:

0:000:x86> ~~[1a38]
   6  Id: 2058.1a38 Suspend: 0 Teb: 7ef94000 Unfrozen
      Start: SogouSoftware_589d0000!_threadstartex (58a5192d) 
      Priority: 0  Priority class: 32  Affinity: f
0:000:x86> ~6s
ntdll_779b0000!ZwWaitForMultipleObjects+0x15:
779d019d 83c404          add     esp,4
0:006:x86> kb
ChildEBP RetAddr  Args to Child              
0370fa5c 768615f7 00000002 0370faac 00000001 ntdll_779b0000!ZwWaitForMultipleObjects+0x15
0370faf8 773519f8 0370faac 0370fb20 00000000 KERNELBASE!WaitForMultipleObjectsEx+0x100
0370fb40 773541d8 00000002 7efde000 00000000 kernel32!WaitForMultipleObjectsExImplementation+0xe0
0370fb5c 589f6ba0 00000002 0370fb84 00000000 kernel32!WaitForMultipleObjects+0x18
0370fbd4 58a51907 58aab894 862df68e 00000000 SogouSoftware_589d0000!CThreadQueue<TagDownloadTask>::ThreadProc+0x100 
0370fc0c 58a51991 00000000 0370fc24 7735336a SogouSoftware_589d0000!_callthreadstartex+0x1b [f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 314]
0370fc18 7735336a 023f5170 0370fc64 779e9882 SogouSoftware_589d0000!_threadstartex+0x64 [f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 292]
0370fc24 779e9882 023f5170 771cc6bb 00000000 kernel32!BaseThreadInitThunk+0xe
0370fc64 779e9855 58a5192d 023f5170 00000000 ntdll_779b0000!__RtlUserThreadStart+0x70
0370fc7c 00000000 58a5192d 023f5170 00000000 ntdll_779b0000!_RtlUserThreadStart+0x1b

6번 스레드가 대기 중입니다. 코드를 대조하면 6번 스레드는 관찰자의 리셋 함수를 CDownloadListUI 클래스의 m 로 호출합니다.vctLock 잠금이지만 콜백 함수가 실행되었습니다.그렇다면 단 한 가지 가능성은 자물쇠가 유출되었다는 것이다. 즉, Lock 이후 잠금이 풀리지 않았다는 것이다.다시 이 리셋 함수를 보니, 과연 아주 드문 지점에서 Unlock 방출 임계구를 호출하지 않고 바로 되돌아온 것이 발견되었고, 이로 인해 고전적인 자물쇠가 유출되어 사라진 자물쇠의 버그를 일으켰다.그렇지만!cs 명령은 이런 상황에서 잘못된 정보를 주었기 때문에 오도하기 쉽고 이 자물쇠를 가진 라인이 퇴출되어 일어난 것이라고 의심할 수 있습니다.이것은 윈드버그의 버그라고 할 수 있겠지.이 상황을 한층 더 테스트한 결과 64비트 시스템에서의 32비트 프로세스에서 발생하는 Dump가 이 문제를 일으킬 수 있음을 발견했습니다. 32비트 시스템에서 발생하는 Dump가 사용됩니다!cs 명령이 정상적으로 실행됩니다.