none
criticalsection blocking RRS feed

  • 질문

  • 다중 스레드의 크리티컬 섹션에서 lock은 걸려있지않은데 블록킹되는 현상이 발생합니다.
    10번에 2~3번 빈도로 발생하며  현재까지 debug 모드 에서만 확인되고 있습니다.
    release 버전에서는 4만회 정도 테스트해본 상황인데 아직 보고되고 있지는 않습니다. 

    디버깅 정보는 아래와 같은데 맨 아래쪽에 보시면 아시겠지만 첫번째는 추적 정보는 대기쓰레드가 혼자인데도 블록킹되고 있습니다;
    이러한 상황 관련 경험이 있으시다면 조언부탁드리겠습니다.

    환경
    windows 7 sp1
    vc++ 2013 pro with mfc

    수정 : analyze -v hang 로그는 헷갈릴것 같아 제외합니다.

    case 1

    ----------------------------------------------------------------------- -----------------------------------------------------------------------                   Starting New Debugger Session         ----------------------------------------------------------------------- ----------------------------------------------------------------------- Microsoft (R) Windows Debugger Version 6.3.9600.17200 X86 Copyright (c) Microsoft Corporation. All rights reserved. *** wait with pending attach Symbol search path is: srv* Executable search path is: ModLoad: 76f30000 770b0000   C:\Windows\SysWOW64\ntdll.dll ModLoad: 756d0000 757e0000   C:\Windows\syswow64\kernel32.dll ... ModLoad: 762b0000 762f5000   C:\Windows\syswow64\WLDAP32.dll (b64.274c): Break instruction exception - code 80000003 (first chance) eax=7ef8d000 ebx=00000000 ecx=00000000 edx=76fcf142 esi=00000000 edi=00000000 eip=76f4000c esp=053ffb44 ebp=053ffb70 iopl=0         nv up ei pl zr na pe nc cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246 ntdll!DbgBreakPoint: 76f4000c cc              int     3

    0:008> !ntsdexts.locks Scanned 343 critical sections

    0:008> ~8kbn  # ChildEBP RetAddr  Args to Child              00 0524ed58 76f7eb4e 00000234 00000000 00000000 ntdll!NtWaitForSingleObject+0x15 01 0524edbc 76f7ea32 00000000 00000000 00000000 ntdll!RtlpWaitOnCriticalSection+0x13e 02 0524ede4 0f57235e 5536b5f4 0524efcc 5536b5e8 ntdll!RtlEnterCriticalSection+0x150 03 0524edf8 55355b4f 0524efc0 0524efcc 00000000 mfc120ud!CCriticalSection::Lock+0x1e 04 0524eee8 55356b2e 0000006a 0524f2ac 0524efcc CommonManager!CCommonManager::GetManager+0x3f 05 0524efc0 00ef9f37 0000006a 0524f238 05165282 CommonManager!GetCommonManager+0x2e ... 14 0524fbb8 76f698f2 00f9ca78 72e8944c 00000000 kernel32!BaseThreadInitThunk+0xe 15 0524fbf8 76f698c5 00f3c170 00f9ca78 00000000 ntdll!__RtlUserThreadStart+0x70 16 0524fc10 00000000 00f3c170 00f9ca78 00000000 ntdll!_RtlUserThreadStart+0x1b

    0:008> !handle 234 f Handle 234   Type          Event   Attributes    0   GrantedAccess 0x100003:          Synch          QueryState,ModifyState   HandleCount   2   PointerCount  4   Name          <none>   Object Specific Information     Event Type Auto Reset     Event is Waiting   0:008> !cs 5536b5f4 ----------------------------------------- Critical section   = 0x5536b5f4 (CommonManager!oInstance+0x2C) DebugInfo          = 0x0079a640 NOT LOCKED LockSemaphore      = 0x234 SpinCount          = 0x00000000

    0:008> !critsec 5536b5f4 CritSec CommonManager!oInstance+2c at 5536b5f4 LockCount          NOT LOCKED RecursionCount     0 OwningThread       0 EntryCount         0 ContentionCount    4 *** Locked

    0:008> dt RTL_CRITICAL_SECTION 5536b5f4 TRExecutor!RTL_CRITICAL_SECTION    +0x000 DebugInfo        : 0x0079a640 _RTL_CRITICAL_SECTION_DEBUG    +0x004 LockCount        : 0n-7    +0x008 RecursionCount   : 0n0    +0x00c OwningThread     : (null)    +0x010 LockSemaphore    : 0x00000234 Void    +0x014 SpinCount        : 0    0:008> ? 0x1 & (-0n7) Evaluate expression: 1 = 00000001

    0:008> ? (0x2 & (-0n7)) >> 1 Evaluate expression: 0 = 00000000

    0:008> ? ((-1) - (-0n7)) >> 2 Evaluate expression: 1 = 00000001


    case 2

    ----------------------------------------------------------------------- -----------------------------------------------------------------------                   Starting New Debugger Session         ----------------------------------------------------------------------- ----------------------------------------------------------------------- Microsoft (R) Windows Debugger Version 6.3.9600.17200 X86 Copyright (c) Microsoft Corporation. All rights reserved. *** wait with pending attach Symbol search path is: srv* Executable search path is: ModLoad: 012b0000 01370000   D:\Binary_12.0\Newronz\Debug\TRExecutor.exe ModLoad: 76f30000 770b0000   C:\Windows\SysWOW64\ntdll.dll ... ModLoad: 6f770000 6f775000   C:\Windows\system32\msimg32.dll (27b0.31a4): Break instruction exception - code 80000003 (first chance) eax=7ef8d000 ebx=00000000 ecx=00000000 edx=76fcf142 esi=00000000 edi=00000000 eip=76f4000c esp=029afa94 ebp=029afac0 iopl=0         nv up ei pl zr na pe nc cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246 ntdll!DbgBreakPoint: 76f4000c cc              int     3

    0:004> !ntsdexts.locks Scanned 372 critical sections

    0:004> !threads Index TID   TEB    StackBase   StackLimit   DeAlloc   StackSize   ThreadProc 0 00003080 0x7efdd000 0x00440000 0x00434000 0x00340000 0x0000c000 0x0 1 00002cec 0x7efda000 0x03ac0000 0x03abf000 0x039c0000 0x00001000 0x0 2 00002cf0 0x7efd7000 0x03ee0000 0x03ede000 0x03de0000 0x00002000 0x0 3 00002f6c 0x7ef9f000 0x040d0000 0x040ce000 0x03fd0000 0x00002000 0x0 4 00002cf8 0x7ef9c000 0x041e0000 0x041de000 0x040e0000 0x00002000 0x0 5 0000260c 0x7ef99000 0x043c0000 0x043bd000 0x042c0000 0x00003000 0x0 6 00001b64 0x7ef96000 0x04690000 0x0468e000 0x04590000 0x00002000 0x0 7 00002460 0x7ef93000 0x048b0000 0x048ae000 0x047b0000 0x00002000 0x0 8 00001114 0x7ef90000 0x04ff0000 0x04feb000 0x04ef0000 0x00005000 0x0 9 000031a4 0x7ef8d000 0x029b0000 0x029ac000 0x028b0000 0x00004000 0x0 Total VM consumed by thread stacks 0x00023000

    0:003> ~6kbn  # ChildEBP RetAddr  Args to Child              00 0468f1ec 76f7eb4e 00000234 00000000 00000000 ntdll!NtWaitForSingleObject+0x15 01 0468f250 76f7ea32 00000000 00000000 0135cf54 ntdll!RtlpWaitOnCriticalSection+0x13e 02 0468f278 0f57235e 5536b5f4 0468f460 5536b5e8 ntdll!RtlEnterCriticalSection+0x150 03 0468f28c 55355b4f 0468f454 0468f460 0135cf54 mfc120ud!CCriticalSection::Lock+0x1e [f:\dd\vctools\vc7libs\ship\atlmfc\include\afxmt.inl @ 111] 04 0468f37c 55356b2e 00000003 0468f54c 0468f460 CommonManager!CCommonManager::GetManager+0x3f 05 0468f454 012c538e 00000003 005ad478 0468f658 CommonManager!GetCommonManager+0x2e ... 0a 0468f858 76f698f2 0135cf54 73bcc10f 00000000 kernel32!BaseThreadInitThunk+0xe 0b 0468f898 76f698c5 012d7a80 0135cf54 00000000 ntdll!__RtlUserThreadStart+0x70 0c 0468f8b0 00000000 012d7a80 0135cf54 00000000 ntdll!_RtlUserThreadStart+0x1b

    0:003> ~5kbn  # ChildEBP RetAddr  Args to Child              00 043bf8c8 76f7eb4e 00000234 00000000 00000000 ntdll!NtWaitForSingleObject+0x15 01 043bf92c 76f7ea32 00000000 00000000 0135cf54 ntdll!RtlpWaitOnCriticalSection+0x13e 02 043bf954 0f57235e 5536b5f4 043bfb3c 5536b5e8 ntdll!RtlEnterCriticalSection+0x150 03 043bf968 55355b4f 043bfb30 043bfb3c 0135cf54 mfc120ud!CCriticalSection::Lock+0x1e [f:\dd\vctools\vc7libs\ship\atlmfc\include\afxmt.inl @ 111] 04 043bfa58 55356b2e 00000003 043bfc28 043bfb3c CommonManager!CCommonManager::GetManager+0x3f 05 043bfb30 012c538e 00000003 005b2428 043bfd34 CommonManager!GetCommonManager+0x2e ... 0a 043bff34 76f698f2 0135cf54 73efc6e3 00000000 kernel32!BaseThreadInitThunk+0xe 0b 043bff74 76f698c5 012d7a80 0135cf54 00000000 ntdll!__RtlUserThreadStart+0x70 0c 043bff8c 00000000 012d7a80 0135cf54 00000000 ntdll!_RtlUserThreadStart+0x1b

    0:003> ~4kbn  # ChildEBP RetAddr  Args to Child              00 041df7dc 76f7eb4e 00000234 00000000 00000000 ntdll!NtWaitForSingleObject+0x15 01 041df840 76f7ea32 00000000 00000000 0135cf54 ntdll!RtlpWaitOnCriticalSection+0x13e 02 041df868 0f57235e 5536b5f4 041dfa50 5536b5e8 ntdll!RtlEnterCriticalSection+0x150 03 041df87c 55355b4f 041dfa44 041dfa50 0135cf54 mfc120ud!CCriticalSection::Lock+0x1e [f:\dd\vctools\vc7libs\ship\atlmfc\include\afxmt.inl @ 111] 04 041df96c 55356b2e 00000003 041dfb3c 041dfa50 CommonManager!CCommonManager::GetManager+0x3f 05 041dfa44 012c538e 00000003 005affe8 041dfc48 CommonManager!GetCommonManager+0x2e ... 0a 041dfe48 76f698f2 0135cf54 73c9c71f 00000000 kernel32!BaseThreadInitThunk+0xe 0b 041dfe88 76f698c5 012d7a80 0135cf54 00000000 ntdll!__RtlUserThreadStart+0x70 0c 041dfea0 00000000 012d7a80 0135cf54 00000000 ntdll!_RtlUserThreadStart+0x1b

    0:003> !handle 234 f Handle 234   Type          Event   Attributes    0   GrantedAccess 0x100003:          Synch          QueryState,ModifyState   HandleCount   2   PointerCount  6   Name          <none>   Object Specific Information     Event Type Auto Reset     Event is Waiting   0:003> !cs 5536b5f4 ----------------------------------------- Critical section   = 0x5536b5f4 (CommonManager!oInstance+0x2C) DebugInfo          = 0x0058a640 NOT LOCKED LockSemaphore      = 0x234 SpinCount          = 0x00000000

    0:003> !critsec 5536b5f4 CritSec CommonManager!oInstance+2c at 5536b5f4 LockCount          NOT LOCKED RecursionCount     0 OwningThread       0 EntryCount         0 ContentionCount    7 *** Locked

    0:003> dt RTL_CRITICAL_SECTION 5536b5f4 TRExecutor!RTL_CRITICAL_SECTION    +0x000 DebugInfo        : 0x0058a640 _RTL_CRITICAL_SECTION_DEBUG    +0x004 LockCount        : 0n-15    +0x008 RecursionCount   : 0n0    +0x00c OwningThread     : (null)    +0x010 LockSemaphore    : 0x00000234 Void    +0x014 SpinCount        : 0    0:003> ? 0x1 & (-0n15) Evaluate expression: 1 = 00000001

    0:003> ? (0x2 & (-0n15)) >> 1 Evaluate expression: 0 = 00000000

    0:003> ? ((-1) - (-0n15)) >> 2 Evaluate expression: 3 = 00000003

    • 편집됨 _sh4dow 2017년 11월 22일 수요일 오전 3:05 수정
    2017년 11월 21일 화요일 오후 3:01

모든 응답

  • 이렇게만 봐서는 모르겠는 데요, 만일, critical section lock을 소유한 thread가 exception등의 여타의 이유로 lock을 해제하지 않고 drop 된 경우가 있을 수 있을 듯하구요, 그렇지 않음 뭔가 3rd party injection 모듈이 잡고 있을 수 있구요. 그러므로, 해당 문제가 발생하기 이전에 1st chance exception을 확인하여 혹시 lock을 소유한 thread에 문제가 있었는 지 tracking 해보시거나 혹은 머신의 3rd party injection할 만한 software를 제거하고 테스트 해보시는 것이 어떨지요...
    2017년 11월 22일 수요일 오전 2:17
  • 이렇게만 봐서는 모르겠는 데요, 만일, critical section lock을 소유한 thread가 exception등의 여타의 이유로 lock을 해제하지 않고 drop 된 경우가 있을 수 있을 듯하구요, 그렇지 않음 뭔가 3rd party injection 모듈이 잡고 있을 수 있구요. 그러므로, 해당 문제가 발생하기 이전에 1st chance exception을 확인하여 혹시 lock을 소유한 thread에 문제가 있었는 지 tracking 해보시거나 혹은 머신의 3rd party injection할 만한 software를 제거하고 테스트 해보시는 것이 어떨지요...

    답변 감사합니다.

    해당 프로세스는 블록킹 상태로 대기중이고 1st chance exception 은 windows User mode debugger 로

    프로세스에 연결하기에 발생하는 예외정보 입니다.

    raw 에서도 발생햇던 기억이라 3rd party injectiond은 배제 가능할것 같은데 혹시 모르니 다시한번 확인은 해봐야 겠네요.

    2017년 11월 22일 수요일 오전 3:11
  • 아.. 제가 말씀드린 1st chance exception은 딱히 80000003 를 말씀드린 것은 아니었고, 문제 재현을 혹시 debugger 를 걸고 재현 하셔서 blocking 상태까지 재현하실 수 있으면 그전에 혹시 발생한 1st chance exception 들 (1st chance Access Violation 포함해서 ..)이 존재하면 한번 살펴보시는 것이 어떨까 의견드린 것입니다. 예를 들어, blocking 이전에 1st chance AV로 인해서 CommonManager쪽 Lock을 소유한 thread가 Lock을 해제하지 못하고 crash나거나 한 것은 아닌지 해서요 드린 의견이었습니다.
    2017년 11월 22일 수요일 오전 4:29