Possibile perdita di memoria Valgrind in OSX El Capitan

Viene visualizzato un avviso per possibly lost: 2,064 bytes in 1 blocks quando si utilizza Valgrind su OSX Yosemite. C'è una soluzione a questo? Ho installato valgrind usando la birra.Possibile perdita di memoria Valgrind in OSX El Capitan

seguito è un esempio di come riprodurre

~/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)

fonte

2016-01-03 Idr

Se non mi dispiacerebbe neanche marcatura mia risposta corretta o pubblicare la tua soluzione, se era diverso, lo apprezzerei :) –

Tbh non ho toccato Valgrind o c per mesi quindi non ho un parere informato su wh è corretto. Qual è il protocollo SO in questa situazione? – Idr

Non sicuro. Immagino che se stai ancora cercando di capire come risolvere il tuo problema o se pensi di provare a risolvere un po 'di tempo in futuro, lascialo fino a quando non trovi che la risposta di qualcuno è stata utile o pubblica la tua risposta. Se hai semplicemente abbandonato il problema del tutto e non hai intenzione di tornare ad esso, allora immagino che potresti anche scegliere una risposta per chiuderla. Puoi sempre cambiare la risposta più tardi se ne esce una migliore –

Valgrind è principalmente uno strumento per Linux, ed è meno supportato per OSX. Ciò significa che Valgrind genererà molti falsi positivi su OSX. Se si desidera eliminare quelle perdite perse, quindi aggiungere il --gen-suppressions=all (o --gen-suppressions=yes se si desidera selezionare e scegliere le perdite segnalate uno per uno) l'opzione per la chiamata valgrind. Che cosa farà è la stampa fuori un pezzo di testo per ogni perdita di memoria riferito che sarà simile a questa:

{ 
    <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 
}

Copia e incolla che, staffe e tutti, ad un qualcosa di file chiamato come /Users/username/leak1.supp. Sentiti libero di cambiare il <...> con un nome effettivo per la tua soppressione. Quindi, quando si chiama valgrind, se si aggiunge un'opzione --suppressions=/Users/<username>/leak1.supp, tale rapporto di perdita di memoria verrà eliminato. Per semplificare, puoi semplicemente inserire le cose in un file ~/.valgrindrc. Questo file potrebbe essere simile a

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

O se si può semplicemente testare il codice su una macchina Linux, invece, non dovrà preoccuparsi di tutto questo;)

--EDIT--

ho un sacco di mie informazioni da this other SO post

fonte

2016-02-24 02:42:16

Come fai a sapere che è un falso positivo? – Idr

In generale non so come diresti se stai vedendo un falso positivo o no, ma nel tuo caso specifico, non stai allocando alcuna memoria, quindi è ragionevole supporre che non stai perdendo qualsiasi memoria. –

ho appena guardato di nuovo l'uscita e vedo roba rapida. Strano!? – Idr

Possibile perdita di memoria Valgrind in OSX El Capitan

risposta

Problemi correlati