C에 ``를 포함하면 Valgrind의 \'아직 도달 가능\' 경고가 나타나는 이유는 무엇입니까?

C에 표준 라이브러리 헤더 포함 및 Valgrind 경고

소개:

이 기사에서는 단순히

프로그램 및 Valgrind 출력:

제공된 코드 조각은 헤더는 있지만 할당을 수행하지는 않습니다.

#include <iostream>

int main() {
  return 0;
}

누수 확인 및 출처 추적이 활성화된 Valgrind를 통해 이 프로그램을 실행하면 다음과 같은 출력이 표시됩니다.

==27671== Memcheck, a memory error detector
... (output truncated)
...
==27671== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==27671==    at 0x4C2AB9D: malloc (vg_replace_malloc.c:296)
==27671==    by 0x4EC060F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
... (output truncated)

이는 72,704바이트가 여전히 있음을 나타냅니다. 프로그램에서 명시적으로 메모리를 할당하지 않아도 접근 가능합니다.

Valgrind's 동작:

Valgrind의 경고가 우려스러울 수 있지만 이것이 C 프로그램의 일반적인 동작이라는 점을 이해하는 것이 중요합니다. C 표준 라이브러리의 많은 구현에서는 파괴된 객체에 대한 메모리를 풀링하고 나중에 재사용하는 자체 메모리 풀 할당자를 사용합니다. 이러한 최적화된 메모리 관리 기술은 메모리 오버헤드를 줄이고 성능을 향상시킵니다.

그러나 Valgrind는 프로그램 종료 시 할당된 모든 메모리를 운영 체제로 반환해야 한다는 가정하에 작동하므로 이러한 풀이 보유한 메모리를 다음과 같이 보고합니다. 아직 도달 가능합니다. 이는 반드시 프로그램이나 Valgrind의 버그가 아니라 기대치의 차이입니다.

C 라이브러리 최적화 비활성화:

Valgrind에서 여전히 도달 가능한 경고를 제거하려면 다음을 수행하십시오. 컴파일러 설정을 수정하여 STL(표준 템플릿 라이브러리) 메모리 풀을 비활성화합니다. 다음은 몇 가지 방법입니다.

__USE_MALLOC 사용:

GCC 버전 2.91~3.1에서는 -D__USE_MALLOC을 사용하여 프로그램을 컴파일하여 STL이 malloc을 사용하고 메모리를 즉시 확보하도록 할 수 있습니다. 그러나 이 옵션은 GCC 3.3 이상에서 제거되었습니다.

환경 변수 사용:

GCC 버전 3.2.2 이상의 경우 프로그램을 실행하기 전에 환경 변수 GLIBCPP_FORCE_NEW를 설정할 수 있습니다. GCC 3.4 이상의 경우 환경 변수 이름은 GLIBCXX_FORCE_NEW입니다.

컴파일러 플래그 사용:

최신 컴파일러에서는 -fno-optimize-sibling-calls 플래그를 사용하여 형제 호출을 비활성화할 수 있습니다. STL 메모리 풀을 포함하는 최적화 최적화.

결론:

헤더만으로는 메모리 누수가 발생하지 않지만 C 라이브러리의 메모리 풀 관리로 인해 Valgrind에서 여전히 도달 가능한 경고가 발생할 수 있습니다. 이 동작은 예상된 동작이며 버그가 아닙니다. STL 최적화를 비활성화하면 이러한 경고가 제거될 수 있지만 성능이 저하될 수 있습니다.

위 내용은 C에 ``를 포함하면 Valgrind의 \'아직 도달 가능\' 경고가 나타나는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!