Ich habe hier Binaries einer Closed Source Software. Diese hat ein Memory Leak, das unter gewissen Anwendungsmustern, die in letzter Zeit gehäuft vorkommen, extrem störend ist, d.h. ständige Neustarts notwendig macht.
Ich habe mir gedacht, dass dieses Problem behoben werden könnte, wenn Aufrufe für malloc() u.ä. von der glibc in eine Library umgebogen würde, die Garbage Collection macht. Dadurch hätte man diese Funktionalität, ohne dass die Software neu compiliert werden müsste (was im Moment nicht möglich ist, da der Source Code nicht verfügbar ist).
Ein ähnliches Vorgehen hat valgrind zur detektierung von Memory Leaks, technisch möglich müsste es also sein, allerdings habe ich nichts dergleichen gefunden. Der Boehm Garbage Collector erfordert anscheinend, dass die Software neu compiliert wird.
> Ein ähnliches Vorgehen hat valgrind zur detektierung von Memory Leaks, > technisch möglich müsste es also sein, allerdings habe ich nichts > dergleichen gefunden. Der Boehm Garbage Collector erfordert anscheinend, > dass die Software neu compiliert wird.
Valgrind bedingt allerdinge erhebliche performance einbußen, um diese
Felherl zu erkennen. Ich denke also, dass so ein garbage collector, so
es ihn gibt, das kaum performant erledigen kann...
> Ich habe hier Binaries einer Closed Source Software. Diese hat ein Memory
> Leak, das unter gewissen Anwendungsmustern, die in letzter Zeit gehäuft
> vorkommen, extrem störend ist, d.h. ständige Neustarts notwendig macht.
> Ich habe mir gedacht, dass dieses Problem behoben werden könnte, wenn
> Aufrufe für malloc() u.ä. von der glibc in eine Library umgebogen würde, die
> Garbage Collection macht. Dadurch hätte man diese Funktionalität, ohne dass
> die Software neu compiliert werden müsste (was im Moment nicht möglich ist,
> da der Source Code nicht verfügbar ist).
das kannst Du guten Gewissens vergessen.
Zwar ist es technisch möglich, die malloc/calloc/realloc/free-Aufrufe umzuleiten falls, und nur falls die Anwendung durchgängig eine DLL-Version der C-Runtime verwendet. Die Vorgehensweise ist im Prinzip per DLL-Rename alle Referenzen der Anwendung auf die Runtime-DLL auf eine eigene DLL umzubiegen. Das kann man binär im Executable patchen.
Die eigene DLL leitet dann alle Runtime-Aufrufe auf die Original-DLL um und ersetzt nur einige Aufrufe. Wenn man es richtig macht, hält sich der Overhead bis hier hin in Grenzen, denn bis auf die ersetzten Aufrufe kann man die Umleitung statisch vom Executable-Loader durchführen lassen, so dass zur Laufzeit wie bisher die Original-Runtime angesprungen wird. Aber ...
> Ein ähnliches Vorgehen hat valgrind zur detektierung von Memory Leaks,
> technisch möglich müsste es also sein, allerdings habe ich nichts
> dergleichen gefunden. Der Boehm Garbage Collector erfordert anscheinend,
> dass die Software neu compiliert wird.
... der Knackpunkt ist, dass die ersetzten Runtime-Funktionen keine Möglichkeit haben, herauszufinden, welche Speicherblöcke tatsächlich noch benötigt werden. Dazu müsste man das Programm komplett auseinander nehmen. Das ist letztlich auch der Ansatz von valgrind, allerdings funktioniert er nicht fehlerfrei. Und außerdem ist das Programm damit nicht mehr produktiv nutzbar.
Programmfehler bleiben Programmfehler. Wenn die Anwendung leckt, hat man eigentlich nur wenige Möglichkeiten.
- Man kann solange mehr Speicher einbauen, bis es nicht mehr so sehr stört.
- Man kann die Anwendung regelmäßig (automatisch) neu starten.
- Wenn die Leckage-Blöcke größer als die System-Page-Size (typ. 4k) sind, kann man einfach großen Swap-Space bereitstellen, und dem Betriebssystem den Rest überlassen. Das führt allerdings zu einer Fragmentierung der Memory-Descriptoren und mithin zu mehr oder minder deutlichen Performance-Verlusten.
> Ich habe hier Binaries einer Closed Source Software. Diese hat ein Memory
> Leak, das unter gewissen Anwendungsmustern, die in letzter Zeit gehäuft
> vorkommen, extrem störend ist, d.h. ständige Neustarts notwendig macht.
> Ich habe mir gedacht, dass dieses Problem behoben werden könnte
*Hüstel* - also wenn die Software von mir ist, habe ich das vorgestern behoben! :o)
Ansonsten solltest Du Dich wirklich an den Hersteller der Software wenden...
> Ein ähnliches Vorgehen hat valgrind zur detektierung von Memory Leaks,
Valgrind beobachtet den Stackpointer sowie parallel malloc()/free() sowie einige andere Aufrufe. Durch diese Beobachtung kann es kurzlebige von langlebigen Objekten unterscheiden.
Häufig wird behauptet, Valgrind fände "Memory Leaks". Das ist so nicht richtig, vielmehr wirft Valgrind alle Objekte raus, die bewiesen kurzlebig sind und daher kein Speicherleck darstellen.
Welche der langlebigen Objekte Speicherlecks sind und welche gültige Daten enthalten muss ein verständiger Mensch entscheiden.
Problem: Das Programm verwendet Threads und da fällt dieser Lösungsweg aufs Maul, auch mit der aktuellsten Entwicklungsversion. Für single-threaded Software würde das aber funktionieren.
Heiko Schlenker <hsch...@gmx.de> wrote:
>* Sven Hartge <sh-...@svenhartge.de> schrieb:
>> Heiko Schlenker <hsch...@gmx.de> wrote:
>>> * Roman Racine <roman.rac...@gmx.de> schrieb:
>>>> Hat jemand hier Vorschläge?
>>> LD_PRELOAD
>> Ich glaube, das kenne Roman. Er sucht nur etwas, _das_ er preloaden
>> kann, welches das malloc(), was ihm Probleme macht, ersetzt bzw.
>> ergänzt.
>Ach so. Dann wäre wohl die Newsgroup de.comp.os.unix.programming
>thematisch besser geeignet.
Warum? Vielleicht sucht er ja nach einer fertigen Library.
Grüße
Marc
-- -------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
