2012-01-27 1 views
4

OSX에서 Valgrind가이 메모리 누수를보고합니다. 어디에서 왔습니까? 코드는 g ++로 C++ 코드로 컴파일됩니다 (함수 오버로딩의 경우이 작업을 수행함).OSX Valgrind에서이 메모리 누수를보고합니다. 어디에서 오는 것입니까?

 
==13088== 18 bytes in 1 blocks are definitely lost in loss record 82 of 264 
==13088== at 0x1F25DC: malloc_zone_malloc (vg_replace_malloc.c:267) 
==13088== by 0xA1AEDA: malloc_set_zone_name (in /usr/lib/system/libsystem_c.dylib) 
==13088== by 0xA1B4A7: _malloc_initialize (in /usr/lib/system/libsystem_c.dylib) 
==13088== by 0xA1B5DD: malloc_good_size (in /usr/lib/system/libsystem_c.dylib) 
==13088== by 0x4EFA6E: __CFStringChangeSizeMultiple (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x4F3900: CFStringAppend (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x506F91: _convertToURLRepresentation (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x60F963: _CFURLInit (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x4FF268: CFURLCreateWithFileSystemPathRelativeToBase (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x4FF8EE: CFURLCreateWithFileSystemPath (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x515735: _CFBundleGetMainBundleAlreadyLocked (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x515663: CFBundleGetMainBundle (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x539533: cacheBundleInfo (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x5394B3: _CFAppVersionCheckLessThan (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x56C35B: __CFInitialize (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) 
==13088== by 0x8FE11243: ImageLoaderMachO::doImageInit(ImageLoader::LinkContext const&) (in /usr/lib/dyld) 
==13088== by 0x8FE10CB3: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld) 
==13088== by 0x8FE0E21F: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) 
==13088== by 0x8FE0E1B5: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) 
==13088== by 0x8FE0F1BF: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld) 
==13088== by 0x8FE03655: dyld::initializeMainExecutable() (in /usr/lib/dyld) 
==13088== by 0x8FE07EF1: dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**) (in /usr/lib/dyld) 
==13088== by 0x8FE012EE: dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*) (in /usr/lib/dyld) 
==13088== by 0x8FE01062: _dyld_start (in /usr/lib/dyld) 
==13088== by 0xFFF: ??? 

편집 : 또한이 메모리를 어떻게 해제합니까?

+0

비슷한 질문 : http://stackoverflow.com/questions/5226691/valgrind-mac-os-mem-leak – bames53

+0

관련 내용 : http://www.mail-archive.com/[email protected] sourceforge.net/msg03053.html – bames53

+0

@ bames53의 차이점은이 누설은 '확실히 잃어버린'범주에 있지만 '아직 도달 할 수 없음'이라는 것입니다. – chacham15

답변

5

할당은 완전히 통제 할 수 없습니다. 무료도 마찬가지입니다. 이것은 알려진, 탐지 된, 기록되었지만 무시 된 항목 목록에 추가되어야합니다 ('억압'은 전문 용어입니다). - printf() 일부를 트리거 할 수

==71989== 
==71989== HEAP SUMMARY: 
==71989==  in use at exit: 6,191 bytes in 33 blocks 
==71989== total heap usage: 33 allocs, 0 frees, 6,191 bytes allocated 
==71989== 
==71989== LEAK SUMMARY: 
==71989== definitely lost: 0 bytes in 0 blocks 
==71989== indirectly lost: 0 bytes in 0 blocks 
==71989==  possibly lost: 0 bytes in 0 blocks 
==71989== still reachable: 6,191 bytes in 33 blocks 
==71989==   suppressed: 0 bytes in 0 blocks 
==71989== Rerun with --leak-check=full to see details of leaked memory 
==71989== 
==71989== For counts of detected and suppressed errors, rerun with: -v 
==71989== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) 

이 명시 적으로 메모리 할당을하지 않는 프로그램입니다 : 나는 맥 OS에 X 10.7.2를 Valgrind의 3.7.0 아래 프로그램을 실행하면

는, 내가 좋아하는 요약을 얻을 할당하지만 대부분의 바이트는 시스템 라이브러리에 할당됩니다. 역 추적 (--num-callers=N)에 대한 정상적인 값보다 명확하게 설정했습니다.

제대로 억제 레코드를 추가하는 방법에 대한 설명서 보이지만 valgrind --help 제공 : 그래서

--num-callers=<number> show <number> callers in stack traces [12] 
--error-limit=no|yes  stop showing new errors if too many? [yes] 
--error-exitcode=<number> exit code to return if errors found [0=disable] 
--show-below-main=no|yes continue stack traces below main() [no] 
--suppressions=<filename> suppress errors described in <filename> 
--gen-suppressions=no|yes|all print suppressions for errors? [no] 

, 당신은 당신이 다음 사용하는 파일에 추가 할 억제 문자열을 생성하는 valgrind를 얻을 수 이후 실행합니다. OS의 X에

Extra options read from ~/.valgrindrc, $VALGRIND_OPTS, ./.valgrindrc 
0

당신이 사용하고있는 라이브러리 중 하나에 더있는 것처럼 보입니다. 그렇다면 라이브러리의 API를 올바르게 사용하고 있는지 확인하십시오. 예를 들어 라이브러리를 초기화 할 때 전역 리소스를 할당하는 경우도 있습니다. 프로그램이 종료 될 때까지는 무료가 아닙니다.

void init_lib(){ 
    static char *buf=NULL; 
    if (buf==NULL) { 
     buf = malloc(18); 
    } 
    ..... 
} 

어떻게 라이브러리가 종료하기 전에이 버퍼를 확보 할 수 있습니다 :

예를 들어, 이러한 상황을 고려? 프로그램이 종료되고 메모리가 OS에서 회수 될 때까지는 불가능합니다. 아래의 설명 중 하나에 의해 제안 기술적으로, 위의 예에서 버피가 free되기를 될 수 있지만, 많은 도서관은 버피가 사용되므로 것을 일을 귀찮게하지 않습니다 :

참조 공통 here

편집 함정 프로그램이 종료 될 때 메모리가 회수되므로 valgrind는이를 메모리 누수로보고합니다.

+0

내가 사용하는 유일한 라이브러리는 SQLite입니다. 나는 그것의 릴리즈 함수를 호출한다. 그래서 나는 그것이 어떻게 문제가 될 수 있는지 보지 않는다. – chacham15

+0

답변에 예제를 추가했습니다. – iabdalkader

+0

종료/정리 전화가 왔습니다. 많은 도서관들이 그러한 행동을하고 있습니다. 그러나, 내가 아는 한, SQLite 않습니다. 나는 osx의 g ++가 핵심 기초 라이브러리를 연결하고 초기화 호출을 추가한다고 생각한다 :'__CFInitialize'. 어떻게 정리를 부를까요? – chacham15

0

당신은 그래 난 당신이 실행하는 OSX의 버전 모르겠습니다 누수 위치

0

에 대한 유용한 정보를 얻을 수 --dsymutil =으로 Valgrind의 실행해야합니다. 하지만 valgrind를 실행중인 버전에서는 그 오류를 무시할 수 있다고보고합니다.