Chtěl bych inzerovat svou právě oznámenou utilitu heaptrack, která by měla být přesně tím, co jste tehdy hledali. Více informací naleznete zde:http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux
Ve srovnání s vaším nástrojem heapwatch by měl být výkon mnohem lepší, protože používám libunwind a později libbacktrace ke zpoždění anotace backtrace s informacemi o ladění DWARF.
Rád bych na to získal další zpětnou vazbu, tak to vyzkoušejte!
memleax by vám měl fungovat.
Ladí únik paměti běžícího procesu tím, že jej připojí, bez rekompilace programu nebo restartování cílového procesu. Je to velmi pohodlné a vhodné pro produkční prostředí.
Zachytává pouze volání malloc/free(), takže by měl mít menší dopad na výkon než Vagrild.
Funguje na GNU/Linux-x86_64 a FreeBSD-amd64.
POZNÁMKA:Jsem autor, každý návrh je vítán
GNU libc má vestavěné ladění malloc:
http://www.gnu.org/software/libc/manual/html_node/Allocation-Debugging.html
Použijte LD_PRELOAD k volání mtrace()
z vašeho vlastního .takže:
#include <mcheck.h>
static void prepare(void) __attribute__((constructor));
static void prepare(void)
{
mtrace();
}
Zkompilujte jej pomocí:
gcc -shared -fPIC dbg.c -o dbg.so
Spusťte jej pomocí:
export MALLOC_TRACE=out.txt
LD_PRELOAD=./dbg.so ./my-leaky-program
Později zkontrolujte výstupní soubor:
mtrace ./my-leaky-program out.txt
A dostanete něco jako:
Memory not freed:
-----------------
Address Size Caller
0x0000000001bda460 0x96 at /tmp/test/src/test.c:7
Samozřejmě, klidně si napište své vlastní malloc háčky, které vysypou celý zásobník (pokud si myslíte, že to pomůže, zavolejte backtrace()).
Čísla řádků a/nebo názvy funkcí bude možné získat, pokud jste někde uložili informace o ladění binárního souboru (např. binární soubor obsahuje nějaké informace o ladění nebo jste to udělali objcopy --only-keep-debug my-leaky-program my-leaky-program.debug
).
Můžete také vyzkoušet Boehmův GC, funguje také jako detektor netěsností:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/leak.html