Pageheap은 힙 손상을 정확히 감지하지 못합니다.
Pageheap은 할당 직후 잘못된 페이지를 삽입합니다. 따라서 할당 된 블록을 오버런 할 때마다 AV를 얻습니다. 그러나 다른 가능한 경우가 있습니다. 한 가지 예는 할당 된 블록이 힙 블록 헤더 데이터 구조를 손상시키기 바로 전에 작성하는 것입니다. 힙 블록 헤더는 유효한 쓰기 가능한 메모리입니다 (대개 할당 된 블록과 동일한 페이지에 있음). 다음 예제를 고려하십시오.
#include <stdlib.h>
int
main()
{
void* block = malloc(100);
int* intPtr = (int*)block;
*(intPtr-1) = 0x12345; // no crash
free(block); // crash
return 0;
}
할당 된 블록이 잘 통과하기 전에 쓰레기를 작성하십시오. Pageheap을 사용하면 예제가 free()
호출 내에서 중단됩니다.
[email protected]() + 0x206 bytes
[email protected]() + 0x239 bytes
[email protected]() + 0x11a bytes
[email protected]() + 0x22 bytes
[email protected]() + 0xe3 bytes
[email protected]() + 0x2f bytes
[email protected]@16() + 0x36919 bytes
[email protected]() + 0x722 bytes
heapripper.exe!free(void * pBlock=0x0603bf98) Line 110 C
> heapripper.exe!main() Line 11 + 0x9 bytes C++
heapripper.exe!__tmainCRTStartup() Line 266 + 0x12 bytes C
[email protected]@12() + 0xe bytes
[email protected]() + 0x27 bytes
[email protected]() + 0x1b bytes
에 pageheap 엄격한 힙 일관성 검사 가능하지만, 검사가 다른 힙 API를 호출 전까지에 걷어차하지 않습니다 여기에 호출 스택입니다. 체크 루틴은 스택에 표시됩니다. (에 pageheap 응용 프로그램이 없으면 유효하지 않은 포인터를 사용하려고 시도하는 힙 구현.에서 아마 AV는 것)
그래서
에 pageheap 당신에게이 발생했을 때 순간에 정확하게 손상을 잡기 위해 100 % 보증을 제공하지 않습니다.
같은 도구가 필요합니다. 또는
Valgrind 모든 메모리 액세스를 추적합니다.
내가 잘못 생각하지 마십시오. Pageheap은 여전히 매우 유용합니다. 언급 된 Purify 및 Valgrind에 비해 성능 저하가 훨씬 적어 훨씬 더 복잡한 시나리오를 실행할 수 있습니다.
힙 손상이 있다고 생각하는 이유가 무엇입니까? 페이지 힙을 사용하도록 설정하면 힙이 손상된 것으로 의심되는 지점에서 충돌이 발생하지 않았을 수 있습니다. 귀하의 응용 프로그램에서 잡기 (...)를 사용하고 계시다면, 실제로 액세스 위반을 감지하여 귀하의 응용 프로그램이 실제로 그 지점에서 충돌하지 않을 것입니다. 페이지 힙을 활성화 한 후에 디버거를 사용하여 앱을 실행 했습니까? (개발자 환경의 VS 또는 프로덕션 환경의 adplus) – DXM
@DXM :/RTC 옵션을 활성화 한 후에 자주 문제가 발생하기 시작했습니다. 나는 모든 ctach (...)를 비활성화했다. 디버깅을 위해 VS dev 환경을 사용하고 있습니다. – Maanu