_ASSERTE(pHead->nBlockUse == nBlockUse); |
warning C4005: macro redefinition; |
의 상관관계 -_-
* 그림이 저작권 때문에 문제가 된다면 내리겠습니다 ㅜㅜ
매크로 재정의 경고..... 아예 무시했었다.
내 경우, 매크로 재정의가 어쩔수 없었던게
한 솔루션 안에 만들어진 프로젝트가 많았는데(한 7개정도?)
그 중에는 API(혹은 단순 C++)도 있었고 MFC도 있었다.
그런데 C++ 쪽에서 릭 체크를 하기 위해
#ifdef _DEBUG #define new new(_CLIENT_BLOCK, __FILE__, __LINE__) #endif
이런 코드를 써놨었다.
이 헤더는 필수라 다른 프로젝트에서도 사용하고 있었고..
그런데 MFC에서 자체적으로
#ifdef _DEBUG #define new DEBUG_NEW #endif
이렇게 써있는게 충돌이 난거다.
그래서 경고가 떴지만, 경고므로, 무시하고 진행했었다.
(심지어 프로젝트 속성에서 아예 경고 무시 설정해놔서 목록에도 안뜨게 해놨었다)
- 왜냐하면, MFC 쪽에 재정의된 부분을 주석처리하면, 에러로 돌변하고(매개변수가 안맞다며),
그걸 맞춰서 사용하면, 어느샌가 IMPLEMENT_DYNCREATE(, ) 부분을 사용할 수 없게 되버리기 때문에...ㅜㅜ
그런데, MFC쪽에서 C++ 클래스를 구현하고 new할당한 후 delete 하는 시점에서 뻑이 나는거다 ㅠㅠ
(프로그램 종료시)
저 위에 있는 Assertion Failed!
근데 아무리 봐도 문법을 위반한 데는 없었고..
추적도 안되는 부분이라
(추적하자면...dbgheap 파일에서 뻑나는데... 이걸 내가 해독할 수 있는것도 아니고...)
계속 검색을 하며 끙끙댔는데
사람들이 말하는 주 원인은
1. 메모리 해제를 중복했을때
2. 메모리 영역과 다른 영역을 해제했을때(영역침범)
이라는데 문제는 짐작가는게 전혀 없다는 거였다.
내가(그리고 많은 사람들이) Safe_Delete라고 지칭하는
if(p) { delete p; p = NULL; }
이 부분을 사용하기 때문에 1번 문제는 날래야 날 수가 없었던 ㅜㅜ
그리고..........
GPG 포럼에서
메모리 오버런일 확률도 있습니다.
new, delete 시에 힙영역에서 몇가지 정보들을 이용하고 바꿉니다.
만약 다른 버그로 인해서 그 메모리를 덮어씌우면
엉뚱하게 new나 delete 에서 에러날수 있습니다.
이때 new, delete 쪽만 뚫어져라보면 절대 잡을수 없습니다.
다른 부분을 봐야합니다.
이런 얘기도 보고.
이런 얘기도 보고.
http://blog.naver.com/smanooo/140087357806
이런 얘기도 보고..하면서
갑자기 문득 떠오르는게 바로 new 재정의였다.
특히 마지막 블로그!
내부적으로 선언된 new 매크로나 할당/해제에 관한글을 세부적으로 풀어 써 주셨는데
그걸 보고 하면서 감이 어느정도 오기 시작했다.
혹시..혹시...호옥시........................
혹시가 사람 잡는거 맞네요.
MFC쪽 프로젝트에서
#ifdef new #undef new #endif
이 소스를 stdafx.h에 포함시켜주니
워닝도 전혀 뜨지않고
끌때 뻑도 안나더이다 ㅇㄱㄴ
전혀 짐작도 못했던 원인과 해결.
그리고 저 undef < 부분은 반은 짐작으로 ㅋㅋ
이렇게 하면 이전 매크로 해제되지 않을까 싶어서 해봤는데 되는거..
어쨌거나 해결! 어렵다 어려워.
'Programming > C/C++' 카테고리의 다른 글
S C++ :: MS의 매직 디버깅 숫자들의 의미 (0) | 2013.03.07 |
---|---|
memset() (0) | 2013.03.07 |