lista aree di memoria "a freddo"

Sto cercando di scovare un bug molto evasive in un software server che assomigliano a una perdita di memoria, ma memcheck non ha aiutato affatto. La mia ipotesi è che la memoria che è stata istanziata e mai rimossa non sia effettivamente trapelata, quindi c'è un riferimento ad essa, ma ora è inutile per il programma e dovrebbe essere rimossa. C'è uno strumento che può contare gli accessi, non i riferimenti, in memoria, e quindi dare una valutazione dell'uso effettivo degli oggetti nell'heap?lista aree di memoria "a freddo"

fonte

2011-12-26 Lorenzo Pistone

Valgrind dovrebbe riferire roba che non è mai stato liberato come "ancora raggiungibile"; vedi http://valgrind.org/docs/manual/faq.html#faq.deflost. –

@oli: potresti pubblicare il tuo commento come risposta in modo che possa essere contrassegnato come accettato. Comunque, sembra la risposta giusta per me. – casualcoder

Ho già eseguito memcheck con questo programma e non ha mostrato nulla. –

ho finito con la mia implementazione strumento. Il mio approccio era leggermente diverso da quello che intendevo: ho scritto un malloc hooking library. Aggancia malloc, realloc e free e mantiene un elenco di blocchi di memoria malloc'a viventi. Ogni volta che si invia un SIGUSR1 alla propria applicazione, esso scarica le informazioni in un file e lo valuta come un'espressione Mathematica. Il notebook Mathematica fornisce infine alcuni grafici molto utili: le istanze con punteggio migliore by call stack e una panoramica completa di calls to malloc. Con questi strumenti, dovevo semplicemente spostare il mio mouse sul punto più grasso e più distante dal punto verde centrale del secondo grafico, e, voilà, ho l'indirizzo che istanzia un sacco di memoria non trapelata ma inutile.

P.S. Le chiamate circolari che puoi vedere nel secondo grafico sono sicuramente un bug in backtrace() di libc.

fonte

2011-12-28 09:35:09

Sono sorpreso che valgrind non abbia fatto quello che volevi, non c'è stata una perdita di memoria che valgrind non ha raccolto per me. – dreamlax

Questo bug è estremamente elusivo per un altro motivo: un altro ragazzo ha trovato un modo per attivarlo in modo affidabile nella sua build, ma quel metodo non funziona per il mio (la stessa fonte fresca e incontaminata, ovviamente). Quindi memcheck non ha trovato nulla di evidente per me, ma questo ragazzo mi ha detto che ha eseguito memcheck e non ha restituito nulla, e non ho motivo di pensare che abbia fatto qualcosa di sbagliato. Anche i dati mostrati nei grafici provengono dalla sua build. Sospetto che sia in qualche modo legato al bitness, costruisce un eseguibile a 32 bit per poter condividere la stessa build su qualsiasi server, mentre io ho creato solo eseguibili a 64 bit. –

Probabilmente questo strumento (Visual Leak Detector) vi aiuterà. È gratuito.

http://vld.codeplex.com/

fonte

2011-12-27 05:55:08 DaddyM

sembra un rilevatore di perdite normale, come ho detto il mio problema è che la memoria extra in uso non è tecnicamente trapelata, perché ci sono ancora riferimenti ad essa. Inoltre, sto lavorando con gcc. –

lista aree di memoria "a freddo"

risposta

Problemi correlati