좋은향기's 프로그램 블로그

Debug-Mode : 메모리의 의미

“초기화 하지 않은 변수는 쓰레기 값으로 채워진다” C/C++책을 한번이라도 주의 깊게 보신 분이라면 한번쯤 접해 보셨을 문구라고 생각됩니다.

하지만 (디버그 빌드에 한하여)이 쓰레기 값이 어떤 의미 있는 값이라는 것은 알고 계신가요?

이 의미 있는 값에 대해 일부 정리 해 보려 합니다.

그렇다면 우리는 해당 메모리 값을 통해 어떤 도움을 받을 수 있을까요?

디버거가 자체 적으로 위 메모리의 값을 기준으로 오류 판단을 하기도 할 뿐아니라,

디버깅 상황에서 몇가지 도움을 얻을 수는 있을 듯 합니다.

예를 들어 메모리를 엑세스 할 때 에러가 발생할 때,

해당 메모리가

n  0xCDCDCDCD로 채워져 있다면, 해당 메모리를 초기화 하지 않고 사용했을 가능성을 용의 선상에 올려 놓을수 있을 테고,

n  0xFEEEFEEE로 채워져 있다면 이미 해제된 메모리를 참조하고 있음을,

n  할당한 메모리의 전/후 경계 부분이 0xFDFDFDFD값이 아니라면 메모리의 범위를 넘어선 write동작을 했음을 유추 할 수 있을 듯 합니다.

문제에 대한 완전한 해결책은 될수 없더라도, 적어도 발생한 문제에 대한 한가지 체크 지점을 발견 할 수도 있다는 얘기가 되겠죠.

ü  메모리 디버깅 관련 참고URL
http://cafe.naver.com/ddugi.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=22&

MFC 전역함수

Watch window formatting Symbols

변수의 값을 확인하기 위해 사용하는 VC++의 Watch Window에서 변수의 값을 원하는 형태로 출력하는 Formatting Symbol에 대해 정리합니다.

n  Number

 

n  String

Symbol	Format
s	String
su	Unicode string
st	Unicode string or ANSI string, depending on Unicode Strings setting in autoexp.dat.

 

n  Memory

Symbol	Format
ma	64 ASCII characters
m	16 bytes in hexadecimal, followed by 16 ASCII characters
mb	16 bytes in hexadecimal, followed by 16 ASCII characters
mw	8 words
md	4 doublewords
mq	4 quadwords
mu	2-byte characters (Unicode)

 

 

 

 

 

 

 

 

n  상수

n  기타

C/C++로 작성한 어플리케이션에서 발생하는 에러중 가장 골치 아픈 에러가 메모리 에러가 아닌가 싶다.( 물론 deadlock이라던가 이런 문제들도 간단친 않지만... )

보통 몇년간 프로그래밍을 하다보면 malloc 혹은 free()를 호출할때(당연히 new/delete도 마찬가지다) 쌩뚱맞게도 메모리 에러가 발생하는 케이스를 경험하게 된다.

처음 이 에러를 접했을때는 '대략난감'이랄까?
하지만 대부분은 '내 잘못'인 에러 케이스다.

이 현상의 대부분은 malloc을 통해 할당받은 메모리의 범위를 넘어서서 데이터를 복사하거나, 이중으로 free를 호출할때 발생한다.

(이 문제는 Windows의 메모리 관리 방법과 밀접한 관계가 있으며, 상기 동작으로 인해 Memory Block의 정보를 담고 있는 Description(?) 영역을 Overwirte해서 발생할 수 있다.- 그림과 함께 좀더 상세한 내용을 기술 하고 싶지만, 아직 내공이 부족해서 ㅡ.ㅡ: 머지 않은 미래에 Study해서 Posting해보려 한다)

예를 들어.

< * free한 메모리에 대해 NULL을 할당하는 것도 좋은 코딩 습관이다. NULL 포인터에 대한 free연산은 적법(?)하다>

이런 경우 코드가 포함되어 있다면, 불특정한 순간에 malloc하거나 free 할때 메모리 에러로 인해 어플이 종료되거나 드라이버의 경우 BSOD를 만나게 된다.
(물론 위와 같이 눈에 띄게 코딩되어 있진 않을꺼라 장담한다 ㅡㅡ)

운이 좋다면 문제 발생 지점의 전후를 살펴보면 문제를 확인 할 수도 있겠지만,
세상일이 어디 그리 만만 하던가?

1. Applicaton Verifier나 gflags를 통해 도움을 받거나,

2. 문제가 발생한 메모리 블록을 추적해서 문제 지점을 유추하거나
3. 그것 마저 여의치 않다면 할당, 해제, 할당한 메모리에 대해 복사하는 코드들에 대한 꼼꼼한 체크가 필요하다.