c OSX एल कैप्टन में संभावित मेमोरी लीक वाल्ग्रिम



macos memory-leaks (1)

possibly lost: 2,064 bytes in 1 blocks लिए मुझे एक चेतावनी मिल रही है possibly lost: 2,064 bytes in 1 blocks ओएसएक्स योसमाइट पर वालग्रिंड का उपयोग करते समय possibly lost: 2,064 bytes in 1 blocks । क्या यह करने के लिए एक तय है? मैं काढ़ा का उपयोग कर valgrind स्थापित किया

नीचे एक पुन: उत्पन्न करने का एक उदाहरण है

~/cat hello.c
int main() {
    return 123;
}

~/uname -a
Darwin mac.local 15.2.0 Darwin Kernel Version 15.2.0: Fri Nov 13 19:56:56 PST 2015; root:xnu-3248.20.55~2/RELEASE_X86_64 x86_64 i386 MacBookAir6,2 Darwin

~/clang --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.2.0
Thread model: posix

~/valgrind --version
  valgrind-3.11.0

~/brew info valgrind
valgrind: stable 3.11.0 (bottled), HEAD
Dynamic analysis tools (memory, debug, profiling)
http://www.valgrind.org/
/usr/local/Cellar/valgrind/3.11.0 (328 files, 46.7M) *
  Poured from bottle
From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/valgrind.rb

~/clang hello.c -o hello.o

~/valgrind --leak-check=full ./hello.o
==7972== Memcheck, a memory error detector
==7972== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7972== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7972== Command: ./hello.o
==7972== 
==7972== 
==7972== HEAP SUMMARY:
==7972==     in use at exit: 22,411 bytes in 187 blocks
==7972==   total heap usage: 271 allocs, 84 frees, 28,651 bytes allocated
==7972== 
==7972== 2,064 bytes in 1 blocks are possibly lost in loss record 57 of 62
==7972==    at 0x10000817C: malloc_zone_malloc (in /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==7972==    by 0x1004F3EFD: _objc_copyClassNamesForImage (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E7182: protocols() (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E7093: readClass(objc_class*, bool, bool) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E4C13: gc_init (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004EC24E: objc_initializeClassPair_internal(objc_class*, char const*, objc_class*, objc_class*) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004F9132: layout_string_create (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E783C: realizeClass(objc_class*) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E7300: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E72E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E72E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==7972==    by 0x1004E72E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib)
==7972== 
==7972== LEAK SUMMARY:
==7972==    definitely lost: 0 bytes in 0 blocks
==7972==    indirectly lost: 0 bytes in 0 blocks
==7972==      possibly lost: 2,064 bytes in 1 blocks
==7972==    still reachable: 0 bytes in 0 blocks
==7972==         suppressed: 20,347 bytes in 186 blocks
==7972== 
==7972== For counts of detected and suppressed errors, rerun with: -v
==7972== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 17 from 17)

वालग्रिंड ज्यादातर लिनक्स के लिए एक उपकरण है, और OSX के लिए कम समर्थित है। इसका मतलब यह है कि वालग्रींड ओएसएक्स पर कई गलत सकारात्मक उत्पन्न करेगा। यदि आप संभवत: खोए गए लीक को दबाने चाहते हैं, तो अपने valgrind कॉल के लिए --gen-suppressions=all (या --gen-suppressions=yes यदि आप चुनते हैं और रिपोर्ट लीक एक एक करके) चुनते हैं तो जोड़ें यह क्या होगा जो प्रत्येक रिपोर्ट किए गए स्मृति रिसाव के लिए पाठ का एक भाग मुद्रित करता है जो इस तरह से कुछ दिखाई देगा:

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: indirect
   fun:malloc
   fun:__Balloc_D2A
   fun:__rv_alloc_D2A
   fun:__dtoa
   fun:__vfprintf
   fun:__v2printf
   fun:vfprintf_l
   fun:printf
   fun:main
}

कॉपी / पेस्ट करें, ब्रैकेट्स और सब कुछ, जैसे कुछ फाइल / /Users/username/leak1.supp । अपने दमन के लिए एक वास्तविक नाम <...> को बदलने के लिए स्वतंत्र महसूस करें फिर जब आप --suppressions=/Users/<username>/leak1.supp कॉल करते हैं, तो अगर आप --suppressions=/Users/<username>/leak1.supp विकल्प --suppressions=/Users/<username>/leak1.supp , तो उस स्मृति रिसाव की रिपोर्ट को दबाया जाएगा। यह आसान बनाने के लिए, आप सिर्फ ~/.valgrindrc फ़ाइल में सामान डाल सकते हैं। यह फाइल कुछ जैसा दिख सकती है

--tool=memcheck
--leak-check=full
--show-reachable=yes
--suppressions=/Users/benlindsay/leak1.supp
--suppressions=/Users/benlindsay/leak2.supp

या यदि आप केवल लिनक्स मशीन पर अपने कोड का परीक्षण कर सकते हैं, तो आपको इसके बारे में चिंता करने की आवश्यकता नहीं होगी;)

--EDIT--

मुझे इस अन्य SO पोस्ट से मेरी बहुत सारी जानकारी मिली है





valgrind