댕글링 포인터(Dangling Pointer)

 

포인터가 여전히 해제된 메모리 영역을 가리키고 있다면, 이러한 포인터를 댕글링 포인터(Dangling Pointer)라고 한다. 댕글링 포인터가 가리키는 메모리는 더는 유효하지 않다. 댕글링 포인터는 premature free(조숙한 해제, 너무 급한 해제)라고 부르기도 한다.

 

 

 

댕글링 포인터의 사용은 아래 목록에 나열된 문제를 포함한 다양한 문제를 야기한다.

 

 

 

- 메모리 접근시 예측 불가능한 동작

 

- 메모리 접근 불가 시 Segmentation fault

 

- 잠재적인 보안 위험

 

 

 

이러한 유형의 문제는 다음과 같은 동작의 결과로 발생한다.

 

 

 

- 메모리 해제 후, 해제된 메모리에 접근

 

- 함수 호출에서 자동 변수를 가리키는 포인터의 반환

 

 

 

 

< 댕글링 포인터 예제 >

 

int * pi = (int * )malloc(sizeof(int)); *pi = 5;  printf("*pi: %d\n", *pi); free(pi);

 

 

free 함수로 메모리를 해제한 후에도 변수 pi는 여전히 메모리의 주소를 가리키고 있다. 그러나 이 메모리는 힙 관리자에 의해 재사용되거나 기존의 정수가 아닌 다른 타입으로도 사용될 수 있다. free 함수를 호출하면 원래 pi 포인터가 가리키고 있던 주소에 위치한 메모리는 해제되며 다시는 사용할 수 없다. 그러나 대부분의 런타임 시스템에서 해제 뒤에 발생하는 메모리의 접근이나 변경을 막지 않는다. 아래 코드에서 보듯이 여전히 해당 메모리에 접근하여 쓰기를 시도할 수 있으며, 이러한 시도의 결과는 예측할 수 없다.

 

 

free(pi); *pi = 10; 

 

 

하나 이상의 포인터가 같은 메모리 영역을 가리키고 그 중 하나가 해제된 경우에는 좀 더 복잡하다. 아래 코드처럼 변수 p1과 p2는 둘 다 같은 메모리 영역을 가리키고 있으며, 이러한 상황을 포인터 에일리어싱(Aliasing)이라고 한다. 그런데, p1이 해제되었다.

 

 

int * p1 = (int *)malloc(sizeof(int)); *pi = 5; ... int * p2; p2 = p1; ... free(p1); ... *p2 = 10;          // p2는 댕글링 포인터이다. 

 

 

또 다른 예제가 있다. 아래 코드와 같이 블록 구문을 사용할 때도 다른 미묘한 문제가 발생한다. 변수 pi에는 tmp의 주소가 할당되며, 변수 pi는 전역 변수이거나 로컬 변수이다. 그러나 변수 tmp는 블록 안에서 선언되고 블록 구문이 닫힐 때 스택에서 제거되며, tmp의 주소는 더는 유효하지 않다.

 

 

int *pi; ... {     int tmp = 5;     pi = &tmp; } // 이 위치에서 pi는 댕글링 포인터가 된다. foo(); 

 

 

 

 

대부분 컴파일러는 블록 구문을 스택 프레임으로 다룬다. 변수 tmp는 블록 안의 스택 프레임에 할당되며, 이어서 블록 구문이 종료되면서 스택 프레임이 제거된다. 블록의 스택 프레임으로 사용된 메모리 영역은 나중에 다른 방식으로 재사용(예제에는 foo함수가 호출되므로 foo함수에 의해 재사용)되며, 변수 pi는 여전히 그 위치를 가리키고 있게 된다.

 

 

 

 

< 댕글링 포인터 다루기 >

 

 

 

포인터가 원인인 문제들의 디버깅은 떄로 해결하기 어려울 때가 있다. 댕글링 포인터 문제를 처리하기 위한 몇 가지 접근 방법을 아래에 나열하였다.

 

 

 

- 메모리 해제 후 포인터를 NULL로 설정하여라.

 

NULL로 설정한 포인터를 그 이후에 사용하면 애플리케이션이 종료할 것이다. 그러나 해당 포인터에 대한 다수의 복사본이 존재할 경우 문제는 여전히 발생한다. 포인터에 NULL을 설정하는 일은 많은 포인터 복사본 중에 단 하나의 포인터에만 영향을 미치기 때문이다. 이와 비슷한 문제를 앞 절 "이중 해제"에서 언급한 적이 있다.

 

- free 함수를 대체할 새로운 함수를 작성하여라.

 

- 몇몇 런타임 시스템이나 디버깅 시스템은 해제된 메모리를 특별한 값으로 덮어쓴다.

 

(예를 들어, 0xDEADBEEF - Visual Studio는 해제된 메모리의 종류에 따라 0xCC, 0xCD, 0xDD 값을 사용하여 덮어쓴다). 예외가 발생하지 않은 상황이라도 프로그래머는 예상치 못한 곳에 이러한 값이 포함된 것을 보고 프로그램이 해제된 메모리에 접근한 것을 알 수 있다.

 

- 댕글링 포인터와 다른 문제들을 발견하기 위해 서드파티 도구들을 사용하라.

 

 

 

 

< 메모리 누수 탐지 기능 >

 

마이크로소프트는 동적으로 할당된 메모리를 덮어쓰는 문제와 메모리 누수 문제를 해결하기 위한 기술을 제공하며, 이 접근 방식은 프로그램의 디버그 버전에서 아래에 나열된 특별한 메모리 관리 기술을 사용한다.

 

 

 

- 힙의 무결성 검사

 

- 메모리 누수 검사

 

- 힙 메모리가 부족한 상황 재현

 

 

 

마이크로소프트는 메모리 할당을 관리하기 위한 특별한 데이터 구조체를 사용한다. 그리고 이 구조체의 사용으로 위와 같은 메모리 관리 기술을 제공한다. 이 구조체는 malloc 함수가 호출된 파일명과 줄 번호와 같은 디버그 정보를 관리한다. 게다가, 메모리를 덮어쓴느 문제를 찾기 위해 메모리 할당 전후로 버퍼가 할당된다. 이 기술에 대한 추가적인 정보는 Microsoft Developer Network(http://bit.ly/12SftWV)에서 찾을 수 있다.

 

 

 

Mudflap 라이브러리(http://bit.ly/YilPI1) 사용하면 GCC에 비슷한 기능을 사용할 수 있다. Mudflap의 런타임 라이브러리는 수많은 기능을 제공하며 그중에서도 특히 메모리 누수 탐지 기능이 제공된다. 이 메모리 누수 탐지 기능은 포인터 역참조 연산들을 계산하고 측정하는 방식으로 수행된다.

 

 

 

 

 

/// 이 글의 출처는 "Understanding and Using C Pointers(리처드 리스 지음)"입니다.

 

This post is some part from the book called "Understanding and Using C Pointers".