이것은 이전 질문 인 Application crash with no explanation의 확장입니다.힙 손상 찾기
응용 프로그램 서버에서 힙 손상으로 인해 많은 크래시가 발생했습니다. 이러한 충돌은 프로덕션에서만 발생합니다. 테스트 환경에서는 재생산 할 수 없습니다.
이러한 충돌을 추적하는 방법을 찾고 있습니다.
Application Verifier가 제안되었으며 괜찮 았지만 프로덕션 서버에서는 사용할 수 없습니다. 응용 프로그램 검증기를 사용하여 프로덕션 환경에서 시작하려고하면 상당히 강력한 서버 (64 비트 응용 프로그램, 16GB 메모리, 8 프로세서)이지만 완전히 사용할 수 없으므로 속도가 느려집니다. 응용 프로그램 검증기없이 실행하면 약 1GB의 메모리 만 사용하고 프로세서주기의 10-15 %를 사용하지 않습니다.
거대한 오버 헤드를 추가하지 않고 힙 손상을 찾는 데 도움이되는 다른 도구가 있습니까?
Microsoft 런타임 라이브러리의 디버그 버전을 사용하십시오. 빨간색 영역 설정을 켜고 초기화 중에 _CrtSetDbgFlag()을 한 번 호출하여 힙 작업을 128 번 (예 : 힙) 작업마다 자동으로 확인하십시오.
_CRTDBG_DELAY_FREE_MEM_DF은 메모리 사용 후 무료 버그를 찾는 데 매우 유용 할 수 있지만 사용하는 동안 힙 크기는 일관되게 증가합니다.
가상화를 실행하고 예약 된 스냅 샷을 찍는 데 어떤 이점이 있습니까? 실제로 충돌이 발생하기 전에 스냅 샷을 얻을 수 있으십니까? 그런 다음 사전 충돌 스냅 샷을 가져 와서 랩 환경에서 시작하십시오. 다시 충돌이 발생하면 스냅 샷을 다시 시작하고 서버 프로세스 검사를 시작하십시오.
우연히 알 수 있습니다. 충돌은 타이밍이 일정하지 않습니다. 완전히 무작위입니다. 서버는 아무런 문제없이 2 시간에서 2 주까지 실행할 수 있습니다. 충돌 직전의 스냅 샷이 있더라도 힙 손상이 발생하는 곳을 찾는데 도움이되지 않습니다. 충돌이 발생했을 때 프로세스 전체를 생성 할 수는 있지만 쓸모가 없습니다. –
자동 스냅 샷을 만드는 방법을 찾을 수있는 한 2 주 동안 실행하도록하십시오. –
나는 당신이 이해할 것 같지 않다. 스냅 샷은 전혀 쓸모가 없다. 힙 손상은 이미 발생했습니다. 나는 그것이 일어나는 때 그것을 붙잡고 일어나기 위하여 그것을 발견 할 필요가있다. –
이것은 시작하는 좋은 방법입니다. 나는 Microsoft의 Application Verifier를 사용하여이를 사용했으며 내가 직면 한 버그를 발견 할 수있었습니다. –