2009-07-24 18 views

risposta

7

non sono troppo familiarità con le heap di debug e STL controlli, ma quando ho problemi di memoria in GCC su linux utilizzare una variabile d'ambiente chiamata MALLOC_CHECK_ (da malloc (3)):

recenti le versioni di Linux libc (successive alla 5.4.23) e GNU libc (2.x) includono un'implementazione di malloc che può essere regolata tramite variabili d'ambiente. Quando viene impostato MALLOC_CHECK_, viene utilizzata un'implementazione speciale (meno efficiente) che è progettata per essere tollerante contro errori semplici, ad esempio chiamate doppie di free() con lo stesso argomento o superamenti di un singolo byte (off-by -uno bug). Tuttavia, non tutti gli errori possono essere protetti da tali errori e possono verificarsi perdite di memoria. Se MALLOC_CHECK_ è impostato su 0, qualsiasi danneggiamento dell'heap rilevato viene silenziosamente ignorato; se è impostato su 1, una diagnostica viene stampata su stderr; se impostato su 2, abort() viene chiamato immediatamente . Questo può essere utile perché in caso contrario un incidente potrebbe verificarsi molto più tardi, e la vera causa del problema è quindi molto difficile da rintracciare.

C'è anche il Recinto Elettrico che può aiutare a catturare i sovraccarichi del buffer interrompendo non appena il sovraccarico/svuotamento avviene. Vedere libefence(3) per ulteriori informazioni.

+0

Questo è esattamente ciò che fa il Debug Heap Peter, grazie! Sai se questi controlli sono fatti anche per nuovi/cancella? – rpg

+0

Lo fa nella mia implementazione (l'eliminazione dell'operatore, almeno, sembra avere una chiamata di base a free(), quindi cattura il double-free). Electric Fence cattura definitivamente i sovraccarichi del buffer con memoria allocata dall'operatore new. –

+0

Si noti che glibc 2.10 e 2.11 sono buggy: MALLOC_CHECK_ può causare blocchi e interruzioni di programmi multi-thread. – ephemient

3

La versione STLport della libreria standard su http://sourceforge.net/projects/stlport/ ha una modalità di debug, che ho usato per utilizzare e che è consigliata da Scott Meyers in STL efficace. Tuttavia, non l'ho usato per diversi anni, quindi non posso garantire lo stato attuale.

C'è anche una discussione sul debug di GCC STL here, ma ancora una volta non posso garantire le informazioni fornite.

+0

Grazie Neil. Preferirei davvero non sostituire l'STL, perché utilizzo librerie di terze parti create con lo STL "standard". – rpg

+1

Purtroppo sarà necessario utilizzare un diverso set di contenitori STL per ottenere il supporto per un debug STL anche se si utilizza un'implementazione di libreria proveniente dallo stesso fornitore della normale libreria.Sono abbastanza sicuro che non ci sia davvero alcun 'debug STL' là fuori dove l'oggetto non cambi il loro layout se stai usando la versione di debug. Quindi IMHO devi andare e ricostruire tutti i componenti con la stessa versione della libreria e le stesse bandiere comunque. –

+0

Per quanto ne so, MSVC ha le funzionalità di debug STL per impostazione predefinita, quindi la versione di debug di una libreria che utilizza lo STL utilizzerà le funzionalità di debug (supponendo che non le disabilitino esplicitamente - il che renderebbe la lib incompatibile con i progetti MSVC predefiniti). Potrei fare uno sforzo e ricostruire, ma mi piacerebbe comunque usare il classico STL se possibile. – rpg

2

Non li ho mai usati, ma so che glibc ha alcune funzionalità per eseguire il debug della memoria allocata dinamicamente. Ecco una voce di manuale pertinente http://www.gnu.org/s/libc/manual/html_node/Memory-Allocation.html#Memory-Allocation. "Allocazione non vincolata" contiene alcune informazioni su vari modi per agganciare le funzioni di allocazione e "Debug di allocazione" contiene alcune informazioni sulla capacità di glibc di tracciare le allocazioni.

Personalmente, penso che Valgrind sia il modo più semplice per farlo.

+0

Sì, ma non posso usarlo con MinGW ... – rpg

3

Alcuni debug heap è disponibile con efence/DUMA (anche in MinGW)

2

Cosa stai cercando può essere attivata attraverso la definizione di _GLIBCXX_DEBUG prima di includere tutte le librerie standard. Non sono sicuro di cosa avrà questo effetto se non puoi usarlo in modo coerente. Il mio consiglio di default sarebbe di essere molto attento. Inoltre ho sentito che i controlli di debug possono essere un grande successo in termini di prestazioni. Così grande che potrebbe non essere saggio averlo sempre abilitato per le build di debug.