Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Garbage Collection ohne neu zu compilieren
1 view
Skip to first unread message
Roman Racine
Feb 7, 2012, 5:34:05 PM2/7/12
to
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.
Hat jemand hier Vorschläge?
Gruss
Roman°
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.
Hat jemand hier Vorschläge?
Gruss
Roman°
Message has been deleted
Sven Hartge
Feb 7, 2012, 8:37:35 PM2/7/12
to
Heiko Schlenker <hsc...@gmx.de> wrote:
> * Roman Racine <roman....@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.
S°
--
Sigmentation fault. Core dumped.
> * Roman Racine <roman....@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.
S°
--
Sigmentation fault. Core dumped.
Stefan Enzinger
Feb 7, 2012, 11:20:51 PM2/7/12
to
On 02/07/2012 11:34 PM, Roman Racine wrote:
> 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
> 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.
Felherl zu erkennen. Ich denke also, dass so ein garbage collector, so
es ihn gibt, das kaum performant erledigen kann...
just my 2 cent
Marcel Müller
Feb 8, 2012, 3:26:38 AM2/8/12
to
Hallo,
On 07.02.2012 23:34, Roman Racine wrote:
> 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.
Marcel
On 07.02.2012 23:34, Roman Racine wrote:
> 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).
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.
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.
Marcel
Edzard Egberts
Feb 8, 2012, 3:41:12 AM2/8/12
to
Roman Racine schrieb:
behoben! :o)
Ansonsten solltest Du Dich wirklich an den Hersteller der Software wenden...
> 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
> 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
behoben! :o)
Ansonsten solltest Du Dich wirklich an den Hersteller der Software wenden...
Florian Weimer
Feb 8, 2012, 4:43:58 AM2/8/12
to
* Roman Racine:
> Der Boehm Garbage Collector erfordert anscheinend, dass die Software
> neu compiliert wird.
Es gab zumindest früher einen Modus, der malloc umschrieb.
> Der Boehm Garbage Collector erfordert anscheinend, dass die Software
> neu compiliert wird.
Jan Kandziora
Feb 8, 2012, 6:18:01 AM2/8/12
to
Roman Racine wrote:
>
> Ein ähnliches Vorgehen hat valgrind zur detektierung von Memory Leaks,
>
Valgrind beobachtet den Stackpointer sowie parallel malloc()/free() sowie
>
> Ein ähnliches Vorgehen hat valgrind zur detektierung von Memory Leaks,
>
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.
Mit freundlichem Gruß
Jan
Message has been deleted
Roman Racine
Feb 8, 2012, 1:00:16 PM2/8/12
to
tatsächlich etwas darüber, dort habe ich bisher nicht gesucht.
Mein Lösungsversuch sieht nun wie folgt aus:
- http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.1.tar.gz
heruntergeladen und entpackt
- configure --prefix=~/gc --enable-redirect-malloc
- make
- make install
- export LD_PRELOAD=~/gc/lib/libgc.so
- Programm ausführen
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.
Gruss
Roman°
Marc Haber
Feb 11, 2012, 9:30:54 AM2/11/12
to
Heiko Schlenker <hsc...@gmx.de> wrote:
>* Sven Hartge <sh-...@svenhartge.de> schrieb:
>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
>* Sven Hartge <sh-...@svenhartge.de> schrieb:
>> Heiko Schlenker <hsc...@gmx.de> wrote:
>>> * Roman Racine <roman....@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
>>> * Roman Racine <roman....@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.
>
>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
0 new messages