glibc: 버전 2.1
gdb
나 루틴 추적 유틸리티인strace
와 ltrace
들과 비교해서 Glibc의 기능을 사용하면 몇 가지 디버깅 장점을 얻을 수 있다.Glibc는 여기에 나오는 주제에 관한 매뉴얼 문서를 자체적으로 가지고 있다. 여기에서는 그 정보를 단순히 옮겨 놓기보다는 요점들만을 다루었다. 그리고 여기에서만 볼 수 있는 정보도 있다.
free
를 호출하거나 malloc
이 채택된 메모리 영역에 1바이트라도 덧쓰기를 하면 Glibc에 세그먼트 오류가 생길 수 있다.이것은 다른 시스템 의 라이브러리들에서는 안보이는 문제이지만, 이러한 버그를 찾는데 도움이 되기 때문에 이것을 Glibc 에서 Malloc을 사용하는 장점이 되고 있다.다시말해, __free
나 chunk_alloc
과 같은 Malloc루틴들 중에서 세그먼트 오류가 발생했다면 이것은 항상 Malloc루틴의 사용으로 인한 결과라는 것이다. 현재까지 알려진 바로는 Glibc의 Maloc 버그는 항상 사용자 프로그램에서만 발생한다고 한다. 세그먼트 오류이외에도 GLibc는 메모리 관련 문제들을 디버깅하는데 도움이 되는 도구들을 몇 가지 갖고 있다.이들 중 대부분은 프로그램의 재작성을 요하는 것이지만, 그렇지 않은 경우도 있다.
malloc
, realloc
,free
의 사용으로 인해 발생하는 버그를 체크해서 막아주는 한 방법은 MALLOC_CHECK_
(Check 다음에도 ''_'이 있다는 것을 잊지 마시오) 환경변수를 설정해 주는 것이다.
MALLOC_CHECK_
환경변수가 설정되면, 간단한 에러는 허용하도록하는 특별한 (하지만 덜효율적인) 설정이 이루어지게 된다.
그래서 같은 인자를 가지고free
호출을 두번하거나 혹은 단일 바이트 를 덮어써도 큰 문제가 되지 않는다. 하지만, 모든 에러에 대하여
보호해 주는 것은 아니며, 때에 따라서는 메모리에 있는 데이터가 사라져 버릴 수도 있다.
MALLOC_CHECK_
변수를 0으로 설정하면, 탐지된 heap corruption이 무시된다.
변수를 1로 설정하면 stderr
에 증상이 기록된다.변수를 2로 설정하면
abort
가 즉시 호출된다.이렇게 해두는 것이 유용한데
그 이유는 만약 나중에 충돌이 생기게되면 그 문재의 원인을 찾기가
힘들어지기 때문이다.
또 다른 방법으로는 메모리 검사를 enable 상태로해서
프로그램을 컴파일하는 것이다. 이에 대한 자세한 사항은 Glibc 매뉴얼을 참조
하라.info libc "Heap Consistency Checking" 호출
)
catchsegv
명령으로 스택 추적 결과를 얻을 수 있다.
인자로서 세그먼트 오류를 야기하는 프로그램 (예를들어 buggy가 인자라면 catchsegv buggy
로 함께 호출된다.)
프로그램에 스택 추적 결과를 만들려면 <execinfo.h>
에 있는 backtrace
기능을 사용한다.
LD_DEBUG
환경변수로 하며, 여기에서 사용할 수 있는 옵션들에는
다음과 같은 것들이 있다.LD_DEBUG=help ls
옵션을
사용하면 다음과 같이 사용할 수 있는 옵션들을 볼 수 있다.
사용 가능한 LD_DEBUG 환경 변수 옵션bindings 심볼 바인딩에 대한 정보 표시 files 파일과 라이브러리 처리표시 help 도움말 표시와 종료 libs 라이브러리 검색 경로 표시 reloc 리로케이션 처리 표시 symbols 심볼 테이블 처리 표시 versions 버전표시
두 개 이상의 옵션을 사용하려면 옵션들 사이에 쉼표로 구분한다.
예를 들면 LD_DEBUG=files,libs program
과 같은 식이다.
ldd
프로그램은 프로그램이나 라이브러리가 의존하고
있는 모든 라이브러리를 리스트로 보여준다.
SDB-aj_debug
)