GDB로 디버깅 할 때 NTDLL 내부의 브레이크 포인트

StackOverflow https://stackoverflow.com/questions/1621059

  •  06-07-2019
  •  | 
  •  

문제

나는 나에게 몇 가지를 자동화하는 매우 간단한 프로그램을 만들었습니다. C ++로 작성하고 Windows에서 실행됩니다. CodeBlocks IDE 내부에서 GDB로 디버깅하는 동안 아무데도 많은 중단 점이 있습니다. 이 문제를 일으킬 수있는 것이 무엇인지 전혀 모른다. 중단 점은 메모리 문제와 관련이있는 것 같습니다 ... 내가 감지 한 메모리 누출을 수정했을 때, 브레이크 포인트 숫자가 훨씬 줄어들 었습니다.

GDB가 나에게 말하는 정확한 것은 다음과 같습니다.

 Program received signal SIGTRAP, Trace/breakpoint trap.
 In ntdll!TpWaitForAlpcCompletion () (C:\Windows\system32\ntdll.dll)

나는 이것을 내 프로그램 내에서 여러 번 얻습니다. 나는 프로그램이 잘 실행되는 것처럼 보이지만 내가 원하는 일을 성취하더라도 매우 잘못된 일을하고 있다고 생각합니다. 내가 어디를보아야하는지 모르기 때문에 누구든지 문제가 무엇인지 말해 줄 수 있습니까? 또한 문제가되지 않으면 아무도 비활성화하는 방법을 아는 사람이 있습니까?

미리 감사드립니다!

편집 : (GDB의 Where 명령의 출력 추가) : 이러한 각 함수가 무엇을하는지 확인할 수 있으므로 내가 무엇을 잘못하고 있는지 확인할 수 있습니까?

#0  0x76fefadd in ntdll!TpWaitForAlpcCompletion () from C:\Windows\system32\ntdll.dll
#1  0x0028e894 in ?? ()
#2  0x76fb272c in ntdll!RtlCreateUserStack () from C:\Windows\system32\ntdll.dll
#3  0x00657fb8 in ?? ()
#4  0x00657fb8 in ?? ()
#5  0x76f4b76a in ntdll!RtlDowncaseUnicodeChar () from C:\Windows\system32\ntdll.dll
#6  0x02070005 in ?? ()
#7  0x00000b10 in ?? ()
#8  0x0028e8dc in ?? ()
#9  0x76ff0b37 in ntdll!TpQueryPoolStackInformation () from C:\Windows\system32\ntdll.dll
#10 0x038b0000 in ?? ()
#11 0x00657fb8 in ?? ()
#12 0x76f4b76a in ntdll!RtlDowncaseUnicodeChar () from C:\Windows\system32\ntdll.dll
#13 0x6e6e9a5e in ?? ()
#14 0x038b0000 in ?? ()
#15 0x038b0000 in ?? ()
#16 0x00000000 in ?? ()
도움이 되었습니까?

해결책

질문은 지금은 꽤 오래되었지만, 여기에 내가했던 것처럼 검색 후 여기에 올 사람이 다음과 같이 도울 수있는 몇 가지 요점이 있습니다.

WinXP에서 개발 한 앱을 Win7에서 테스트하는 동안 그 문제가 발생했습니다. 필자의 경우 Windows 7 메모리 관리 모니터링 및 내 앱의 잘못된 메모리 할당과 관련이 있습니다.

스토리를 짧게 만들기 위해 앱 코드에서 오류로 인해 청구 된 메모리 블록 (사용하는 대신 GlobalAlloc()) 그리고 a GlobalFree() (C 런타임 메모리 풀의 포인터로 시스템 힙에 액세스함에 따라 잘못되었습니다). 이것은 (이 경우 매우 작은) 메모리 누출을 일으키고 있지만 WinXP에서 테스트하는 동안 완전히 눈에 띄지 않았으며 전체 프로그램이 정확하게 올바르게 실행되었습니다.

이제 Win7에서 실행되면 메모리 모니터링 기능이라는 결함 허용 힙 (Fth) 앱 의이 버그를 감지합니다 (예외를 일으킨).

  • 동시에 OutputDebugString() (또는 아마도 DbgPrint()) 단순을 사용하여 볼 수 있습니다 디버그 뷰 도구 또는 응용 프로그램 추적시 도구 또는 디버거에 의해. 따라서 수신 된 신호 직전에 메시지에서 그런 것을 볼 수 있습니다.

    경고 : 힙 [name_of_your.exe] :

    경고 : RTLFreeHeap에 지정된 잘못된 주소 (006b0000, 006A3698)

  • 그리고 (앱이 디버깅되는 경우) 디버거 외부에 영향을 미치지 않는 중단 점을 출력하지만 문제를 지적하는 데 도움이됩니다. 해당 중단 점은 GDB에 의해 SIGTRAP 신호로 표시됩니다..

이 시점에서 두 가지 대안이 있습니다.

  • 콜 스택을 걸어 코드에서 결함이있는 명령을 찾으십시오 (불행히도,이 경우에는 bt 또는 where GDB 명령은 내 코드에서 힙이 잘못 풀린 위치를 볼 수있을만큼 멀리 표시 할 수 없습니다. 누군가 NTDLL 대신 시작 모듈에서 올바른 통화 스택을 표시하는 방법을 알고 있다면 알려주세요.)
  • FTH가 버그를 둘러싼 시도로 자동 패치를 유지할 수있는 능력을 갖기 때문에 계속 노력하십시오 (다음 번 앱 실행에서 자동 패치가 미리 발생할 수 있음).

Moshe Levi가 말했듯이 힙 문제 당시 멈추지 않기 때문에 handle SIGTRAP nostop 앱을 시작하기 전에 GDB 프롬프트에서

요컨대 : 예, 메모리 관리에 비해 코드에 문제가 있었지만 경우에 따라 충돌없이 실행할 수 있습니다. 그러나 디버그 모드에서 커널은 문제의 경로를 입력하려고합니다.

다른 팁

와우, 당신은 내가 Linux 플랫폼에서 GDB를 사용했을 때 5 년을 돌려 보냈습니다 :)

다음 명령으로 SIGTRAP을 수신 할 때 GDB가 파손되지 않도록 할 수 있습니다.

handle SIGTRAP nostop

그러나 나는 여기 Steve와 함께 있습니다. 대신 Windbg를 시도하십시오. 특히 Windows 용으로 제작되었습니다.

기본 Windows 디버거 인 WindBG를 사용하는 것이 좋습니다. 이것은 커널 모드로 전환 할 때 특히 심볼에 대해 더 나은 스택 추적을 제공합니다.

방금 QT Creator와 GCC/MINGW를 사용 하여이 충돌을 경험했습니다.

나는 틀린 것처럼 보이는 변수 (6 바이트 x x x x 씩 오프셋)를 포함하여 다른 문제도 가지고있었습니다. 제 경우에는 코드에 혼란을 일으킨 프라그마 팩으로 판명되었습니다.

나는 이것을 가지고 있었다 :

#pragma pack(1)
typedef struct SomeStruct
{
... // structure
} SomeStruct;

... 그러나 나는 구조 후 1의 1의 포장을 종료하기 위해 Pragma Pack () 호출로 종료하지 않았고 기본 바이트 정렬/포장으로 돌아갑니다. 고정 된 추가 :

#pragma pack(1)
typedef struct SomeStruct
{
... // structure
} SomeStruct;
#pragma pack() // <<-- with this line the heap corruption problem was stopped
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top