ओएसएक्स एल कैपिटन

में संभावित मेमोरी लीक वालग्रिंड ओएसएक्स योसेमेट पर वालग्रिंड का उपयोग करते समय मुझे 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)

स्रोत

2016-01-03 Idr

मेरी जानकारी का एक बहुत कुछ मिला है, मैं इसकी सराहना करता हूँ :) –

Tbh मैं वेलग्रिंड छुआ है या महीनों के लिए सी तो मुझे wh के बारे में एक सूचित राय नहीं है सही है इस स्थिति में एसओ प्रोटोकॉल क्या है? – Idr

सुनिश्चित नहीं है। मुझे लगता है कि अगर आप अभी भी अपने मुद्दे को हल करने का तरीका समझ रहे हैं या यदि आप भविष्य में कुछ समय हल करने का प्रयास करने की योजना बना रहे हैं, तो इसे तब तक छोड़ दें जब तक आप पाते हैं कि किसी का उत्तर उपयोगी था या बस अपना उत्तर पोस्ट करें। अगर आप पूरी तरह से समस्या को त्याग देते हैं और इसे वापस आने की योजना नहीं बनाते हैं, तो मुझे लगता है कि आप इसे बंद करने का उत्तर भी चुन सकते हैं। यदि कोई बेहतर व्यक्ति –

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

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

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

की तरह कुछ दिखाई दे सकता है या यदि आपने अभी बजाय एक Linux मशीन पर अपने कोड का परीक्षण कर सकते हैं, तो आप इस सब के बारे में चिंता करने की ज़रूरत नहीं होगी;)

--EDIT--

मैं आप या तो कोई फ़र्क नहीं पड़ेगा अगर मेरे जवाब सही अंकन या अपने समाधान पोस्टिंग अगर यह अलग था से this other SO post

स्रोत

2016-02-24 02:42:16

बाहर आता है तो आप हमेशा उत्तर बदल सकते हैं कि आप कैसे जानते हैं कि यह एक गलत सकारात्मक है? – Idr

आम तौर पर मुझे नहीं पता कि आप कैसे झूठी सकारात्मक देख रहे हैं या नहीं, लेकिन आपके विशिष्ट मामले में, आप किसी भी स्मृति को आवंटित नहीं कर रहे हैं, इसलिए यह मानना उचित है कि आप लीक नहीं कर रहे हैं कोई स्मृति –

बस आउटपुट को फिर से देखा और मैं तेज़ सामान देखता हूं। अजीब!? – Idr

ओएसएक्स एल कैपिटन

उत्तर

संबंधित मुद्दे