Visual Studio 2008에서 (네이티브) 멀티 스레드 C ++ 응용 프로그램을 디버깅하고 있습니다. 임의의 경우에 "Windows가 중단 점을 트리거했습니다 ..."라는 오류가 발생합니다. 더미. 이 오류가 응용 프로그램을 즉시 중단 시키지는 않지만 곧 중단 될 수 있습니다.
이러한 오류의 큰 문제는 실제로 손상이 발생한 후에 만 오류가 발생하여 특히 다중 스레드 응용 프로그램에서 추적 및 디버깅이 매우 어렵다는 것입니다.
어떤 종류의 일이 이러한 오류를 일으킬 수 있습니까?
어떻게 디버깅합니까?
팁, 도구, 방법, 깨달음은 환영합니다.
답변:
Windows 용 디버깅 도구 와 결합 된 Application Verifier 는 놀라운 설정입니다. Windows 드라이버 키트 또는 더 가벼운 Windows SDK 의 일부로 둘 다 얻을 수 있습니다 . ( 힙 손상 문제에 대한 이전 질문을 조사 할 때 Application Verifier에 대해 알게 되었습니다 .) 과거에도 BoundsChecker 및 Insure ++ (다른 답변에서 언급)를 사용했지만 Application Verifier의 기능이 얼마나 많은지 놀랐습니다.
Electric Fence (일명 "efence"), dmalloc , valgrind 등은 모두 언급 할 가치가 있지만 대부분 Windows보다 * nix에서 실행하기가 훨씬 쉽습니다. Valgrind는 엄청나게 융통성이 있습니다. 대용량 서버 소프트웨어를 사용하여 많은 힙 문제를 디버깅했습니다.
다른 모든 방법이 실패하면 자체 글로벌 운영자에게 new / delete 및 malloc / calloc / realloc 과부하를 제공 할 수 있습니다. 그렇게하는 방법은 컴파일러와 플랫폼에 따라 조금씩 다를 수 있으며 이는 약간의 투자입니다. 그러나 장기적으로 보답 할 수 있습니다. 바람직한 기능 목록은 dmalloc과 electricfence, 놀랍게도 훌륭한 Writing Writing Solid Code :
로컬 홈브류 시스템 (내장 된 대상의 경우)에서는 런타임 오버 헤드가 훨씬 높기 때문에 추적을 다른 항목과 별도로 유지합니다.
이러한 할당 기능 / 오퍼레이터를 오버로드해야하는 더 많은 이유에 관심이있는 경우 "전역 오퍼레이터를 새로로드하고 삭제하는 이유는 무엇입니까?"에 대한 나의 대답을 살펴보십시오. ; 뻔뻔한 자체 홍보 외에 힙 손상 오류를 추적하는 데 도움이되는 기타 기술과 기타 적용 가능한 도구가 나열되어 있습니다.
MS가 사용하는 alloc / free / fence 값을 검색 할 때 여기에서 내 자신의 답변을 계속 찾기 때문에 Microsoft dbgheap fill values에 대한 다른 답변이 있습니다 .
응용 프로그램에 대해 페이지 힙을 활성화하여 많은 힙 손상 문제를 감지 할 수 있습니다. 이렇게하려면 Windows 용 디버깅 도구 의 일부로 제공되는 gflags.exe를 사용해야 합니다.
Gflags.exe를 실행하고 실행 파일의 이미지 파일 옵션에서 "페이지 힙 사용"옵션을 선택하십시오.
이제 exe를 다시 시작하고 디버거에 연결하십시오. 페이지 힙을 사용하면 힙 손상이 발생할 때마다 응용 프로그램이 디버거로 침입합니다.
매우 관련이있는 기사는 Application Verifier 및 Debugdiag를 사용한 디버깅 힙 손상입니다 .
어떤 종류의 일이 이러한 오류를 일으킬 수 있습니까?
버퍼 종료 후 쓰기 또는 버퍼가 힙으로 다시 해제 된 후 버퍼에 쓰기와 같이 메모리로 나쁜 일을하는 것.
어떻게 디버깅합니까?
실행 파일에 자동화 된 경계 검사를 추가하는 도구를 사용하십시오 (예 : Unix의 valgrind) 또는 Windows의 BoundsChecker (Wikipedia는 Purify 및 Insure ++도 제안합니다)와 같은 도구를 사용하십시오.
이로 인해 응용 프로그램이 느려질 수 있으므로 응용 프로그램이 소프트 실시간 응용 프로그램 인 경우 사용하지 못할 수 있습니다.
또 다른 가능한 디버깅 보조 도구는 MicroQuill의 HeapAgent 일 수 있습니다.
사용 가능한 메모리에 대한 액세스 감지 에서 얻은 한 가지 빠른 팁 은 다음과 같습니다.
메모리 블록에 액세스하는 모든 명령문을 확인하지 않고 오류를 빠르게 찾으려면 블록을 해제 한 후 메모리 포인터를 유효하지 않은 값으로 설정할 수 있습니다.
#ifdef _DEBUG // detect the access to freed memory #undef free #define free(p) _free_dbg(p, _NORMAL_BLOCK); *(int*)&p = 0x666; #endif
내가 유용하고 매번 사용할 수있는 최고의 도구는 코드 검토 (좋은 코드 검토 자 포함)입니다.
코드 검토 외에 먼저 Page Heap을 시도 합니다. 페이지 힙을 설정하는 데 몇 초가 걸리며 운이 좋으면 문제가 발생할 수 있습니다.
Page Heap이 마음에 들지 않으면 Microsoft에서 Windows 용 디버깅 도구를 다운로드 하고 WinDbg 사용 방법을 배우십시오. 더 구체적인 도움을 줄 수는 없지만 멀티 스레드 힙 손상을 디버깅하는 것은 과학보다 예술입니다. "WinDbg 힙 손상"에 대한 Google의 경우 주제에 대한 기사를 많이 찾을 수 있습니다.
동적 또는 정적 C 런타임 라이브러리에 링크되어 있는지 확인할 수도 있습니다. DLL 파일이 정적 C 런타임 라이브러리에 연결되어 있으면 DLL 파일에 별도의 힙이 있습니다.
따라서 한 DLL에서 개체를 만들고 다른 DLL에서 해제하려고하면 위에서 본 것과 동일한 메시지가 나타납니다. 이 문제는 다른 DLL에 할당 된 메모리 해제 다른 스택 오버플로 질문에서 참조됩니다 .
어떤 유형의 할당 기능을 사용하고 있습니까? 최근에 Heap * 스타일 할당 함수를 사용하여 비슷한 오류가 발생했습니다.
HEAP_NO_SERIALIZE옵션으로 힙을 실수로 생성 한 것으로 나타났습니다 . 따라서 본질적으로 힙 기능이 스레드 안전없이 실행됩니다. 올바르게 사용하면 성능이 향상되지만 다중 스레드 프로그램에서 HeapAlloc을 사용하는 경우 사용해서는 안됩니다 [1]. 귀하의 게시물에 멀티 스레드 응용 프로그램이 있다고 언급했기 때문에 이것을 언급합니다. HEAP_NO_SERIALIZE를 어디에서나 사용하는 경우이를 삭제하면 문제가 해결 될 수 있습니다.
[1] 이것이 합법적 인 특정 상황이 있지만 Heap *에 대한 호출을 직렬화해야하지만 일반적으로 다중 스레드 프로그램에는 해당되지 않습니다.
이러한 오류가 임의로 발생하면 데이터 레이스가 발생할 가능성이 높습니다. 확인하십시오 : 다른 스레드에서 공유 메모리 포인터를 수정합니까? 인텔 스레드 검사기는 다중 스레드 프로그램에서 이러한 문제를 감지하는 데 도움이 될 수 있습니다.
_CrtSetDbgFlag에 대해 VC CRT 힙 검사 매크로를 사용할 수 있습니다 . _CRTDBG_CHECK_ALWAYS_DF 또는 _CRTDBG_CHECK_EVERY_16_DF .. _CRTDBG_CHECK_EVERY_1024_DF .
내 경험을 추가하고 싶습니다. 지난 며칠 동안 응용 프로그램 에서이 오류의 인스턴스를 해결했습니다. 필자의 경우 코드의 오류는 다음과 같습니다.
Control.Invoke콜백이 속한 기본 개체를 래핑하는 관리되는 개체를 호출 하고 폐기합니다.Control.Invoke종료 될 때까지 콜백 호출에서 차단 된 상태로 유지 됩니다). 내가 사용한다는 것을 명확히해야 boost::thread하므로 멤버 함수를 스레드 함수로 사용합니다.Control.BeginInvoke객체가 파괴되기 전에 원시 스레드가 종료되도록 콜백의 목적을 사용하십시오 (콜백의 목적은 스레드가 종료되어 객체가 파괴 될 수 있음을 정확하게 알려줍니다).