Leichtes Debuggen von Speicherlecks unter Linux

Ich habe zuerst nach vorhandenen Antworten gesucht und das gesehen Valgrind ist jedermanns beliebtestes Tool zum Debuggen von Speicherlecks unter Linux. Leider Valgrind scheint für meine Zwecke nicht zu funktionieren. Ich werde versuchen zu erklären, warum.

Einschränkungen:

• Das Leck reproduziert sich nur in der Umgebung des Kunden. Aufgrund bestimmter rechtlicher Einschränkungen müssen wir mit bestehenden Binärdateien arbeiten. Keine Umbauten.
• In einer normalen Umgebung verbraucht unsere Anwendung ~10 % CPU. Angenommen, wir können eine bis zu 10-fache Erhöhung der CPU-Auslastung tolerieren. Valgrind mit Vorgabe memcheck
  Die Einstellungen sind viel schlimmer und machen unsere Anwendung für längere Zeit nicht mehr reaktionsfähig.

Was ich brauche, ist ein Äquivalent von Microsoft UMDH: Stack-Tracing für jede Heap-Zuordnung einschalten, dann zu einem bestimmten Zeitpunkt alle Zuordnungen gruppiert nach Stacks und nach Zuordnungsanzahl in absteigender Reihenfolge sortieren. Unsere App wird sowohl auf Windows- als auch auf Linux-Plattformen ausgeliefert, daher kenne ich diese Leistung unter Windows UMDH ist noch erträglich.

Hier sind die Tools/Methoden, die ich in Betracht gezogen habe

• Valgrind‘s -Speichercheck und -Massiv Tools Sie tun viel mehr als nötig (wie das Scannen des gesamten Prozessspeichers nach jedem Zuordnungszeiger), sie sind zu langsam und sie tun immer noch nicht genau das, was ich
  brauche (Dump-Callstacks sortiert nach Anzahl), also muss ich einige Skripte schreiben, die die Ausgabe parsen
• dmalloc Die Bibliothek (dmalloc.com) erfordert eine neue Binärdatei
• LeakTracer (http://www.andreasen.org/LeakTracer/) Funktioniert nur mit C++
  neu/löschen (Ich brauche malloc/frei auch) hat keine Gruppieren-nach-Stapel- und Sortierfunktion
• Das Tool selbst als .so-Bibliothek mit dem LD_PRELOAD-Mechanismus implementieren (Überschreiben von ‘malloc’ mit dem LD_PRELOAD-Mechanismus) Das wird angesichts meiner Programmierkenntnisse für Linux mindestens eine Woche dauern und es fühlt sich an, als würde man ein Fahrrad erfinden.

Habe ich etwas vergessen? Gibt es Leichtgewichte Valgrind Optionen oder vorhandenes LD_PRELOAD-Tool?

GNU libc hat eingebautes Malloc-Debugging:

http://www.gnu.org/software/libc/manual/html_node/Allocation-Debugging.html

Verwenden Sie zum Aufrufen LD_PRELOAD mtrace() von Ihrem eigenen .so:

#include <mcheck.h>
static void prepare(void) __attribute__((constructor));
static void prepare(void)
{
    mtrace();
}

Kompilieren Sie es mit:

gcc -shared -fPIC dbg.c -o dbg.so

Führen Sie es aus mit:

export MALLOC_TRACE=out.txt
LD_PRELOAD=./dbg.so ./my-leaky-program

Überprüfen Sie später die Ausgabedatei:

mtrace ./my-leaky-program out.txt

Und Sie erhalten so etwas wie:

Memory not freed:
-----------------
           Address     Size     Caller
0x0000000001bda460     0x96  at /tmp/test/src/test.c:7

Natürlich können Sie gerne Ihre eigenen Malloc-Hooks schreiben, die den gesamten Stack ausgeben (calling Rückverfolgung () wenn du denkst, dass das hilft).

Zeilennummern und/oder Funktionsnamen sind verfügbar, wenn Sie Debug-Informationen für die Binärdatei irgendwo gespeichert haben (z. B. hat die Binärdatei einige Debug-Informationen eingebaut, oder Sie haben es getan objcopy --only-keep-debug my-leaky-program my-leaky-program.debug).

Sie können auch Boehms GC ausprobieren, es funktioniert auch als Lecksucher:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/leak.html

Ich möchte mein gerade angekündigtes Heaptrack-Dienstprogramm bewerben, das genau das sein sollte, wonach Sie damals gesucht haben. Weitere Informationen finden Sie hier: http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux

Im Vergleich zu Ihrem Heapwatch-Tool sollte die Leistung weitaus besser sein, da ich libunwind und später libbacktrace verwende, um die Annotation des Backtrace mit DWARF-Debug-Informationen zu verzögern.

Ich würde gerne mehr Feedback dazu bekommen, also probiere es aus!

memleax sollte für dich funktionieren.

Es debuggt Speicherlecks eines laufenden Prozesses, indem es angehängt wird, ohne das Programm neu zu kompilieren oder den Zielprozess neu zu starten. Es ist sehr bequem und für die Produktionsumgebung geeignet.

Es TRAPt nur für Aufrufe von malloc/free(), daher sollte es weniger Leistungseinbußen bringen als Vagrild.

Es funktioniert unter GNU/Linux-x86_64 und FreeBSD-amd64.

HINWEIS: Ich bin der Autor, jeder Vorschlag ist willkommen

MemoryScape würde Ihren Anforderungen entsprechen. Dies ist das dynamische Speicher-Debugging-Tool, das mit dem geliefert wird TotalView Debugger.

http://www.roguewave.com/products/memoryscape.aspx

@glagolig,

Ja, MemoryScape kann Zuordnungen nach Stack-Speicherort gruppieren.

Konnten Sie die Evaluierungsversion erhalten? Angenommen, Sie haben eine E-Mail-Adresse verwendet, die nicht wie ein Bot aussieht, sollten Sie ziemlich schnell von uns gehört haben. Wenn nicht, oder wenn Sie technische Probleme damit haben, rufen Sie mich an oder wenden Sie sich an unser technisches Support-Team.

Chris Gottbrath

Hauptproduktmanager für TotalView bei Rogue Wave Software

E-Mail: Vorname . Nachname (at) Roguewave . com

Überraschenderweise konnte ich nichts wie Microsofts UMDH in einer Open-Source-Domäne oder zum sofortigen Download finden. (habe ich auch angeschaut Google Heap Leak Checker aber es ähnelt eher Valgrind als UMDH). Also habe ich das Tool schließlich selbst geschrieben Malloc-Instrumentierung Projekt als Bezugspunkt:

https://github.com/glagolig/heapwatch

Das Tool hat eine Reihe von Einschränkungen, aber es hat für meine Zwecke gut funktioniert.

Es gibt ein kostenloses Open-Source-Tool namens chap, das das meiste von dem tut, was Sie wollen. Es gibt Ihnen insbesondere keine Stack-Traces, aber es ist ein extrem leichtes Werkzeug, da es überhaupt keine Instrumentierung erfordert. Alles, was Sie brauchen, ist in der Lage zu sein, einen Live-Kern des betreffenden Prozesses zu einem Zeitpunkt zu erfassen, an dem Sie glauben, dass der Prozess den Fehler bereits gezeigt hat (Sie glauben also, dass er durchgesickert ist oder zu groß ist oder was auch immer).

Einzelheiten finden Sie unter https://github.com/vmware/chap