허상 포인터
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
허상 포인터는 C 및 C++과 같은 프로그래밍 언어에서 메모리 해제 후에도 해당 메모리 주소를 계속 가리키는 포인터를 의미하며, 이는 프로그램 오류 및 보안 취약성의 원인이 된다. 허상 포인터는 메모리 해제 후 포인터를 널(null)로 설정하지 않거나, 스택 프레임 파괴, 초기화되지 않은 포인터 사용, `malloc()`과 `free()`의 잘못된 사용 등으로 인해 발생한다. 이러한 문제는 "use after free" 취약점과 같은 보안 허점으로 이어질 수 있으며, 권한 상승 또는 정보 유출을 야기할 수 있다. 허상 포인터 문제를 해결하기 위해 안전한 해제 함수 사용, C++ 스마트 포인터, 가비지 컬렉션, Rust의 타입 시스템과 같은 다양한 기술이 사용된다. 또한 널 포인터 역참조, 디버깅 도구, 특수 패턴으로 덮어쓰기 등의 기법을 통해 허상 포인터를 탐지할 수 있다.
더 읽어볼만한 페이지
- 소프트웨어 버그 - 교착 상태
교착 상태는 둘 이상의 프로세스가 자원을 점유하고 서로의 자원을 요청하여 더 이상 진행할 수 없는 상태를 의미하며, 상호 배제, 점유 대기, 비선점, 순환 대기 네 가지 조건이 모두 충족되어야 발생하고, 운영 체제는 이를 예방, 회피, 무시, 발견하는 방법으로 관리한다. - 소프트웨어 버그 - 글리치
글리치는 예기치 않은 오작동이나 오류를 뜻하며, 전자 공학, 컴퓨터, 비디오 게임, 텔레비전 방송, 대중문화 등 다양한 분야에서 기능 실패, 오류, 그래픽 및 사운드 문제, 신호 오류 등의 이상 현상을 포괄적으로 지칭하는 용어이다. - 취약점 공격 - 보안 취약점
보안 취약점은 시스템의 설계, 구현, 운영, 관리상 결함이나 약점으로, 위협에 의해 악용되어 시스템 보안 정책을 위반할 수 있는 요소이며, ISO 27005, IETF RFC 4949, NIST SP 800-30, ENISA 등 다양한 기관에서 정의하고 있다. - 취약점 공격 - 인터넷 보안
인터넷 보안은 사이버 위협, 악성 소프트웨어, 서비스 거부 공격 등으로부터 정보와 시스템을 보호하기 위해 네트워크 계층 보안, 다단계 인증, 방화벽 등 다양한 기술과 방법을 포괄한다.
| 허상 포인터 | |
|---|---|
| 일반 정보 | |
| 유형 | 포인터 |
| 정의 | 유효한 객체를 가리키지 않는 포인터 |
| 상세 정보 | |
| 발생 원인 | 객체가 삭제된 후 포인터가 재설정되지 않음 객체가 스코프 밖으로 벗어난 후 포인터가 재설정되지 않음 |
| 문제점 | 메모리 접근 오류 프로그램 충돌 보안 취약점 |
| 방지 방법 | 포인터 사용 후 항상 `NULL` 또는 `nullptr`로 설정 스마트 포인터 사용 가비지 컬렉션 사용 |
| 관련 용어 | 메모리 누수 세그멘테이션 오류 참조 횟수 약한 참조 |
2. 허상 포인터의 원인
많은 프로그래밍 언어에서 메모리의 객체를 명시적으로 지우거나, 함수 반환 시 스택 프레임이 파괴되어도 관련 포인터는 변경되지 않는다. 이러한 포인터는 참조가 삭제되고 다른 용도로 사용되고 있더라도 여전히 같은 메모리 위치를 가리킨다.
C 언어의 경우 다음과 같은 경우에 허상 포인터가 발생한다.
- `malloc()`과 `free()`를 사용하여 동적으로 할당된 메모리를 해제한 후에도 해당 포인터를 계속 사용하는 경우
- 함수 내 지역 변수의 주소를 반환하여 함수가 종료된 후에도 해당 포인터를 사용하는 경우
운영 체제가 널 포인터에 대한 런타임 참조를 감지할 수 있다면, 내부 블록이 종료되기 직전에 포인터에 0 (null)값을 주는 것이 해결책이 될 수 있다. 다른 해결책으로는 추후의 초기화 없이 포인터가 다시는 사용되지 못하게 하는 것이 있다.[3]
흔히 하는 실수로 스택에 할당된 지역 변수의 주소를 반환하는 것이 있다. 호출된 함수가 반환되면, 이 변수들을 위한 공간은 할당 해제되고, "쓰레기 값"을 갖게 된다.[5] 함수 호출 이후에 포인터로 값을 읽으면 아직은 정확한 값을 반환할 수 있지만, 이후에 호출된 다른 함수가 스택 저장소를 겹쳐쓸 수 있으므로 더 이상 정확한 값을 갖지 못한다. 이러한 경우, 변수를 `static`으로 선언하여 함수 범위를 벗어나도록 해야 한다.[6]
2. 1. 메모리 해제 후 참조
많은 프로그래밍 언어에서 메모리 객체를 명시적으로 제거하거나, 함수 반환 시 스택 프레임이 파괴되어도 관련 포인터는 변경되지 않는다. 이러한 포인터는 참조가 삭제되고 다른 용도로 사용되고 있더라도 여전히 같은 메모리 위치를 가리킨다.`free()` 함수 등을 사용하여 메모리를 해제한 후에도 해당 포인터를 계속 사용하는 경우 허상 포인터가 발생한다. 이는 C/C++에서 흔히 발생하는 실수이다.[1]
다음은 허상 포인터가 발생하는 예시이다.[2]
```c
{
char *dp = NULL;
/* ... */
{
char c;
dp = &c;
} /* c의 범위를 벗어남 */
/* dp는 이제 허상 포인터임 */
}
```
위 코드에서 내부 블록이 종료되기 직전에 `dp`에 0 (널 포인터)을 할당하거나, 추가 초기화 없이 `dp`가 다시 사용되지 않도록 보장하여 허상 포인터 문제를 해결할 수 있다.[3]
`malloc()`과 `free()` 라이브러리 호출을 혼용하여 사용할 때도 허상 포인터가 자주 발생한다. 포인터가 가리키는 메모리 블록이 해제되면 해당 포인터는 허상 포인터가 된다. 이를 방지하기 위해 참조를 해제한 후에는 포인터를 널(null)로 재설정하는 것이 좋다.[4]
```c
#include
void func() {
char *dp = malloc(A_CONST);
/* ... */
free(dp); /* dp는 이제 허상 포인터가 됨 */
dp = NULL; /* dp는 더 이상 허상 포인터가 아님 */
/* ... */
}
```
스택에 할당된 지역 변수의 주소를 반환하는 것 또한 흔한 실수이다. 함수가 반환되면 해당 변수의 공간은 할당 해제되고, 이 변수들은 "쓰레기 값"을 가지게 된다.[5]
```c
int *func(void) {
int num = 1234;
/* ... */
return #
}
```
함수 호출 후 포인터를 읽으면 잠시 동안은 정확한 값(1234)을 반환할 수 있지만, 이후 호출된 다른 함수가 스택 저장소를 덮어쓰면 더 이상 정확한 값을 보장할 수 없다. 이러한 경우, `num`을 `static`으로 선언하여 함수 범위를 벗어나도록 해야 한다.[6]
2. 2. 스택 프레임 파괴
C 프로그래밍 언어와 같은 많은 언어에서 함수 호출이 끝나고 스택 프레임이 제거될 때, 해당 프레임 내의 지역 변수를 가리키던 포인터는 허상 포인터가 된다. 이러한 포인터는 참조가 삭제되고 다른 목적에 쓰이고 있더라도 계속 같은 위치를 가리킨다.다음은 스택 프레임 파괴로 인해 허상 포인터가 발생하는 간단한 예시이다.[1]
```c
{
char *dp = NULL;
/* ... */
{
char c;
dp = &c;
}
/* c의 범위가 벗어남 */
/* dp는 이제 허상 포인터임 */
}
```
위 코드에서 내부 블록이 종료되면 지역 변수 `c`는 범위를 벗어나게 된다. 따라서 `c`를 가리키던 `dp`는 허상 포인터가 된다. 운영 체제가 널 포인터에 대한 런타임 참조를 감지할 수 있다면, 내부 블록이 종료되기 직전에 `dp`에 0 (null)값을 주는 것이 해결책이 될 수 있다. 다른 해결책으로는 추후의 초기화 없이 `dp`가 다시는 사용되지 못하게 하는 것이 있다.[2]
스택에 할당된 지역 변수의 주소를 반환하는 것도 흔한 실수이다. 호출된 함수가 리턴되면, 이 변수들을 위한 공간은 할당 해제되고, "쓰레기 값"을 갖게 된다.[3]
```c
int *func(void)
{
int num = 1234;
/* ... */
return #
}
```
함수 호출 이후에 포인터로 값을 읽으면 아직은 정확한 값(1234)을 반환할 수 있지만, 이후에 호출된 다른 함수가 스택 저장소를 겹쳐쓸 수 있으므로 더 이상 정확한 값을 갖지 못하게 된다. `num`에 대한 포인터가 반환되어야 한다면, `num`은 이 함수 이상의 유효 범위를 가져야 하며, 이것은 `static`으로 정의함으로써 가능해질 수 있다.[4]
3. 와일드 포인터의 원인
와일드 포인터는 처음 사용할 때 초기화를 생략하여 발생한다. 초기화가 강제되지 않는 언어의 모든 포인터는 와일드 포인터로 시작된다고 할 수 있다.[1]
이는 대부분 초기화를 생략하는 것이 아니라 초기화를 건너뛰면서 발생하며, 대부분의 컴파일러는 이에 대해 경고한다.[1]
3. 1. 초기화 누락
포인터 변수를 선언한 후 아무 값으로도 초기화하지 않고 사용하면 허상 포인터가 발생한다. C/C++ 컴파일러는 종종 이에 대해 경고하지만, 모든 경우를 잡아내지는 못한다.[1]```c
int f(int i)
{
char *dp; /* dp는 허상 포인터이다. */
static char *scp; /* scp는 허상 포인터가 아니다.
- 정적 변수는 0으로 초기화된다.
- 시작할 때와 마지막 호출 이후 값을 유지한다.
- 이 기능을 사용하는 것은 주석이 없으면
- 좋지 않은 스타일로 간주될 수 있다. */
}
4. 허상 포인터와 관련된 보안 허점
버퍼 오버플로와 유사하게, 허상 포인터 또는 와일드 포인터 버그는 보안 허점으로 이어질 가능성이 높다. 가상 함수 호출 시 vtable 포인터가 덮어씌어져 다른 주소를 호출하게 되거나, 포인터가 메모리 쓰기에 사용될 때 다른 데이터 구조를 손상시킬 수 있다.
많은 언어(예: C 프로그래밍 언어)에서 메모리의 객체를 명시적으로 삭제하거나 스택 프레임 반환 시 관련 포인터는 변경되지 않는다. 포인터는 해당 위치가 다른 용도로 사용될 수 있음에도 불구하고 메모리의 동일한 위치를 계속 가리킨다.
다음은 C 언어 코드 예시이다.
{
char *dp = NULL;
/* ... */
{
char c;
dp = &c;
}
/* c의 범위가 벗어남 */
/* dp는 이제 허상 포인터임 */
}
위 문제의 해결책은 내부 블록이 종료되기 직전에 `dp`에 0(널)을 할당하는 것이다. 또 다른 해결책은 추가 초기화 없이 `dp`가 다시 사용되지 않도록 보장하는 것이다.
허상 포인터의 또 다른 원인은 `malloc()` 및 `free()` 라이브러리 호출의 뒤섞인 조합이다. 포인터가 가리키는 메모리 블록이 해제될 때 포인터는 허상이 된다. 이를 방지하는 한 가지 방법은 참조를 해제한 후 포인터를 널로 재설정하는 것이다.
다음은 C 언어 코드 예시이다.
#include
void func()
{
char *dp = malloc(A_CONST);
/* ... */
free(dp); /* dp는 이제 허상 포인터가 됨 */
dp = NULL; /* dp는 더 이상 허상 포인터가 아님 */
/* ... */
}
스택에 할당된 지역 변수의 주소를 반환하는 것도 흔한 실수이다. 호출된 함수가 반환되면 이러한 변수의 공간은 할당 해제되고 기술적으로 "가비지 값"을 갖게 된다.
다음은 C 언어 코드 예시이다.
int *func(void)
{
int num = 1234;
/* ... */
return #
}
`func` 호출 후 얼마 동안은 포인터에서 읽으려고 시도하면 여전히 올바른 값(1234)이 반환될 수 있지만, 그 이후에 호출된 모든 함수는 `num`에 할당된 스택 스토리지를 다른 값으로 덮어쓸 수 있으며 포인터는 더 이상 제대로 작동하지 않는다. `num`에 대한 포인터를 반환해야 하는 경우, `num`은 함수 범위를 벗어나야 하며, static으로 선언될 수 있다.
허상 포인터가 새로운 메모리 청크 할당 없이 해제된 후 사용될 때, "use after free" 취약점으로 악용될 수 있다.[10]
4. 1. 권한 상승 및 정보 유출
버퍼 오버플로와 마찬가지로 허상 포인터 버그는 보안 취약점으로 이어질 수 있다. 가상 함수 호출 시 vtable 포인터가 덮어씌어져 다른 주소를 호출하게 되거나, 포인터가 메모리 쓰기에 사용될 때 다른 데이터 구조를 손상시킬 수 있다.[10]허상 포인터가 된 후 메모리를 한 번만 읽더라도 정보 유출이나 권한 확대로 이어질 수 있다. 허상 포인터가 새로운 메모리 청크 할당 없이 해제된 이후에 사용되면 "use after free" 취약점으로 악용된다.[10] 예를 들어, 은 Microsoft Internet Explorer 6에서 11까지의 use-after-free 취약점이며, 제로데이 공격을 통해 지능형 지속 위협에 사용되었다.[5][6]
4. 2. 임의 코드 실행
버퍼 오버플로와 마찬가지로, 허상 포인터는 보안 취약점으로 이어질 수 있다. 해제된 메모리 영역을 가리키는 허상 포인터는 공격자가 해당 영역을 조작하여 악의적인 코드를 삽입하고 실행하는 데 사용될 수 있다.[4]예를 들어, 포인터가 가상 함수 호출에 사용될 때, vtable 포인터가 덮어씌어져 다른 주소(악성 코드)를 호출할 수 있다. 또는 포인터를 사용하여 메모리에 쓰기를 할 경우, 다른 데이터 구조가 손상될 수 있다. 허상 포인터가 된 후 메모리를 한 번만 읽어도 정보 유출이나 권한 확대로 이어질 수 있다.[4]
허상 포인터가 새로운 메모리 청크 할당 없이 해제된 후에 사용되면, "use after free" 취약점으로 악용될 수 있다.[4] 마이크로소프트 인터넷 익스플로러 6부터 11까지에서 발견된 use-after-free 취약점()은 제로데이 공격을 통해 지능형 지속 위협에 사용되었다.[5][6] 이러한 공격은 시스템 전체를 장악하는 결과로 이어질 수 있다.
5. 허상 포인터 회피
허상 포인터 문제를 해결하기 위한 다양한 기법들이 존재한다.
C 언어에서는 가장 간단한 방법으로, 포인터 재설정을 보장하는 `free()` 함수의 대체 버전을 구현하는 방법이 있다. 그러나 이 방법은 포인터의 복사본을 가진 다른 포인터 변수들까지는 처리하지 못한다.[3]
```c
#include
#include
/* 'free()'의 대체 버전 */
static void safefree(void **pp)
{
/* 디버그 모드에서 pp가 NULL이면 중단 */
assert(pp);
/* free(NULL)은 제대로 작동하므로 디버그 모드에서 assert 외에는 확인할 필요가 없습니다. */
free(*pp); /* 청크 할당 해제, free(NULL)은 유효합니다. */
}
```
`#define` 지시자를 사용하여 매크로를 정의하면 편리하게 사용할 수 있다. (일반적으로 `#define XFREE(ptr) safefree((void **)&(ptr))`) 그러나 이 기법을 사용하는 프로그래머는 `free()`가 사용되는 모든 곳에서 안전한 버전을 사용해야 한다. 또한 이 해결책은 단일 프로그램 또는 프로젝트 범위로 제한되며 적절히 문서화해야 한다.[3]
C와 C++에서 표준 메모리 할당 함수를 가비지 컬렉터로 대체하는 보수적인 가비지 컬렉터인 Boehm 가비지 컬렉터를 사용하여, 해제를 비활성화하고 가비지 컬렉션을 통해 객체를 회수하여 허상 포인터 오류를 완전히 제거할 수 있다.
안토니 크레츠마르(Antoni Kreczmar, 1945–1996)는 허상 참조 현상이 없는 완벽한 객체 관리 시스템을 만들었다.[2] 비슷한 접근 방식이 피셔(Fisher)와 르블랑(LeBlanc)에 의해 ''잠금-키''(Locks-and-keys)라는 이름으로 제안되었다.[3]
Rust 언어에서는 타입 시스템이 변수 생명 주기 및 자원 획득은 초기화를 포함하도록 확장되었다. 언어의 기능을 비활성화하지 않으면 허상 포인터는 컴파일 시간에 포착되어 프로그래밍 오류로 보고된다.
5. 1. 안전한 해제 함수 사용
c
#include
#include
/* 'free()'의 대체 버전 */
void safefree(void **pp) {
assert(pp); // 디버그 모드에서는 pp가 NULL이면 중단
if (pp != NULL) { // 안전 검사
free(*pp); // 청크 할당 해제, free(NULL)은 유효
}
}
```
C 프로그래밍 언어에서는 `free()` 함수 대신 포인터를 `NULL`로 초기화하는 안전한 버전의 해제 함수를 직접 구현하여 사용할 수 있다. 위의 `safefree()` 함수는 이중 해제(Double Free) 오류를 방지하는 데에도 도움이 된다.[3]
`safefree()` 함수의 사용 예시는 다음과 같다.
```c
int f(int i) {
char *p = NULL, *p2;
p = (char *)malloc(1000); // 메모리 청크 할당
p2 = p; // 포인터 복사
/* 여기서 청크 사용 */
safefree((void **)&p); // 안전하게 해제; p2 변수에는 영향 없음
safefree((void **)&p); // 두 번째 호출은 p가 NULL로 재설정되었으므로 실패하지 않음
char c = *p2; // p2는 여전히 허상 포인터이므로, 이는 정의되지 않은 동작
return i + c;
}
```
`safefree()` 함수는 `p`를 `NULL`로 설정하므로 두 번 호출해도 프로그램이 중단되지 않는다. 그러나 이 함수는 다른 포인터 변수 (위의 예시에서 `p2`)까지 `NULL`로 만들지는 못한다.[3]
`malloc()` 호출 이전에 빈 포인터의 유효성을 보장하는 데 사용될 수 있다.
```c
safefree(&p); /* 청크가 해제되었는지 확실하지 않음 */
p = malloc(1000); /* 지금 할당 */
```
`#define` 지시자를 사용하여 매크로를 생성하면 편리하게 사용할 수 있다. (예: `#define XFREE(ptr) safefree((void **)&(ptr))`) 그러나 이 기법을 사용하는 프로그래머들은 `free()`가 사용되는 모든 부분에서 안전한 버전을 사용해야 한다. 그렇지 않으면 문제가 다시 발생한다. 또한 이 해결책은 단일한 프로그램이나 프로젝트로 제한되며, 적절히 문서화되어야 한다.[3]
5. 2. 스마트 포인터 (C++)
C++에서 댕글링 포인터를 피하는 데 널리 사용되는 기술은 스마트 포인터를 사용하는 것이다.[3] 스마트 포인터는 일반적으로 참조 카운팅을 사용하여 객체의 수명을 관리한다.[3]
5. 3. 가비지 컬렉션 (Java, C# 등)
Java나 C# 같은 언어에서는 메모리를 명시적으로 할당 해제하는 메커니즘이 없기 때문에 허상 포인터가 발생할 수 없다. 대신 가비지 컬렉터가 객체가 더 이상 어떤 참조에서도 도달할 수 없는 경우에 메모리를 할당 해제한다.[3]
5. 4. 소멸자(RAII)를 이용한 자원관리
C++에서는 스마트 포인터(smart pointers)를 사용하여 자원 관리 문제를 해결한다. 스마트 포인터는 일반적으로 참조 횟수 계산 방식을 사용하여 객체를 재활용한다. 다른 해결책으로는 톰스톤(tombstones) 기법과 락앤키(locks-and-keys) 기법이 있다. 이러한 접근 방식은 `free()`를 비활성화하고 쓰레기 수집(Garbage Collection)으로 객체를 재활용함으로써 허상 포인터를 완전히 제거한다.
자바 같은 언어에서는 메모리 할당 해제를 명시적으로 하는 메커니즘이 없기 때문에 허상 포인터가 발생하지 않는다. 대신에 쓰레기 수집기(garbage collector)가 객체가 어떤 참조에서도 닿을 수 없는 경우에 메모리를 할당 해제한다.
6. 허상 포인터 탐지
허상 포인터를 탐지하는 일반적인 기법은 포인터가 가리키는 저장 공간이 해제될 때 널 포인터나 유효하지 않은 주소로 포인터를 설정하는 것이다. 널 포인터를 역참조하면 프로그램이 즉시 종료되므로, 데이터 손상이나 예측할 수 없는 동작 없이 프로그래밍 실수를 쉽게 찾고 해결할 수 있다. 그러나 이 방법은 포인터의 복사본이 여러 개 있는 경우에는 효과가 없다.[11]
몇몇 디버거들은 할당 해제된 데이터를 `0xDEADBEEF` 같은 특정한 패턴으로 자동 덮어쓴다. (마이크로소프트의 Visual C/C++ 디버거는 무엇이 할당 해제되었는지에 따라 `0xCC`, `0xCD` 또는 `0xDD`를 사용한다.[11]).
Polyspace, TotalView, Valgrind, Mudflap,[12] AddressSanitizer, 또는 LLVM[13] 기반 도구들을 사용하여 허상 포인터 사용을 탐지할 수 있다. SoftBound와 CheckPointer 같은 다른 도구들은 합법적인 포인터 값들을 추적하고, 각 접근의 유효성을 검사하여 소스 코드를 기구화한다.
의심되는 클래스 집합이 작을 경우, 모든 멤버 함수를 임시로 virtual로 만들어 가상 메소드 테이블을 활용하는 전략도 있다.
6. 1. 널 포인터 역참조 시 프로그램 종료
포인터를 해제한 후 `NULL`로 설정하면, 널 포인터를 역참조할 때 프로그램이 즉시 종료되어 문제를 쉽게 찾을 수 있다. 이 방식은 근본적인 프로그래밍 실수를 더 쉽게 찾고 해결할 수 있게 해준다.[11]6. 2. 디버깅 도구 활용
Polyspace, Valgrind, AddressSanitizer, LLVM[13] 기반 도구는 허상 포인터 사용을 탐지하는 데 사용될 수 있다. 이러한 도구는 런타임에 메모리 접근 오류를 검사하여 문제를 보고한다.6. 3. 특수 패턴으로 덮어쓰기
일부 디버거는 할당 해제된 데이터를 `0xDEADBEEF` 같은 특정한 패턴으로 자동 덮어쓴다. (마이크로소프트의 Visual C/C++ 디버거는 무엇이 할당 해제되었는지에 따라 `0xCC`, `0xCD` 또는 `0xDD`를 사용한다.[11]). 이 방식은 데이터를 쓸모없게 만들어 재사용을 막는다.7. 기타 해결 방안
안토니 크레츠마르(1945–1996)는 허상 참조 현상이 없는 완벽한 객체 관리 시스템을 개발했다.[2] 피셔와 르블랑은 이와 비슷한 접근 방식을 ''잠금-키''(Locks-and-keys)라는 이름으로 제안했다.[3]
참조
[1]
웹사이트
Warning Options - Using the GNU Compiler Collection (GCC)
https://gcc.gnu.org/[...]
[2]
논문
Programmed deallocation without dangling reference
[3]
논문
The implementation of run-time diagnostics in Pascal
[4]
웹사이트
CWE-416: Use After Free
https://cwe.mitre.or[...]
Mitre Corporation
2014-04-28
[5]
웹사이트
CVE-2014-1776
https://web.archive.[...]
2017-05-16
[6]
웹사이트
New Zero-Day Exploit targeting Internet Explorer Versions 9 through 11 Identified in Targeted Attacks
http://www.fireeye.c[...]
FireEye
2014-04-28
[7]
문서
Visual C++ 6.0 memory-fill patterns
http://msdn2.microso[...]
[8]
문서
Mudflap Pointer Debugging
https://gcc.gnu.org/[...]
[9]
논문
Efficiently Detecting All Dangling Pointer Uses in Production Servers
http://llvm.org/pubs[...]
[10]
웹인용
CWE-416: Use After Free
https://cwe.mitre.or[...]
Mitre Corporation
2012-05-11
[11]
문서
Visual C++ 6.0 memory-fill patterns
http://msdn2.microso[...]
[12]
문서
Mudflap Pointer Debugging
http://gcc.gnu.org/w[...]
[13]
논문
Efficiently Detecting All Dangling Pointer Uses in Production Servers
http://llvm.org/pubs[...]
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com