logo http://www.cbmamiga.demon.co.uk/mpatrol/

mpatrol

Autor: Gerrit Bruchhäuser

Quellenverzeichnis:

Die Homepage

Einleitung

Besondere Mermale
Die Installation
Einbinden der Bibliothek
MPATROL_OPTIONS

Download: mpatrol-1.4.8.tar.gz


Einleitung

Mpatrol wurde vor einigen Jahren von Graeme Roy, zum finden eines vermeitlichen Memory leaks (generiert von einem C++ Compiler den seine Firma hergestellt hatte), auf einer Amiga 4000/040 programmiert. Weiterentwickelt hat er mpatrol dann auf Red Had Linux 6.2.

Eigentlich wollte er damals dann die Bibliothek an seine Firma weiter verkaufen, was ihm aber nicht gelang. Er fand mpatrol aber so gut gelungen und auch viel zu schade um die berreits investierte Zeit einfach so zu löschen, dass er sich entschloss sie zu veröfentlichen.

Mitlerweile hat sich das aussehen der Bibliothek tramatisch von der ursprunglichen Version geändert. So hat sich Greame zum Beispiel dafür entschieden die Bibliothek auf Qualität und Quantität der Fehlermeldungen zu optimieren, was bei den ersten Versionen bei weitem noch nicht der Fall war.

Generell kann man sagen das mpatrol eine ganze menge Fehler finden kann, die z.B. andere tools wie dmalloc oder dbmalloc nicht finden.

Der Nachteil von mpatrol ist das mit dieser Bibliothek übersetzte Programme deutlich langsamer werden und extrem mehr Speicher brauchen. Auch ist die Portierung von mpatrol auf andere (ältere) Systeme problematisch. Auf einer Compaq Tru64 V.4.0, wird man zum Beispiel kein Glück haben.

Wie auch immer gibt es keinerlei Probleme auf Linux und Solaris. Es sei hier angemerkt das Graeme selbst Solaris, neben Red Had Linux auf einer Intel Platform, als das referenz System von mpatrol ansieht.

Besondere Merkmale

  • Zeigt ein Abbild des Stacks bei einem Fehler an.
  • Datei- und Zeilen informationen werden mit ausgegeben.
  • Ist kompatibel zu dmalloc, dbmalloc, insure und purify
  • Wird ständig weiter entwickelt.
  • Graeme bietet support bei problemen. Man kann ihn z.B. in seinem Forum um Rat fragen.
  • Man muss nicht umbedingt neu übersetzen um seine Programme mit mpatrol zu testen.
  • Findet alle denkbaren Fehler auf dem Heap. Fehler auf dem Stack werden nicht gefunden.
  • Bietet eine erstklassige Dokumentation.

Um sein Programm mit mpatrol zu testen ist genau wie bei den meisten Anderen tools ein überschreiben der Speicher anfordernden- und freigebenden Aufrufe notwendig. Bei mpatrol kann man dies nun auf zwei Arten machen. Einmal kann man zum sein Programm zu der statischen oder dynamischen Bibliothek linken, oder man bindet diese später durch einen Aufruf von:

mpatrol --dynamc ./testprog -i file

dynamisch mit in sein Programm ein. Die letzte möglichkeit funktioniert allerdings nur wenn das Programm schon dynamisch zur standart C Bibliothek übersetzt wurde und selbst dann nur auf einigen wenigen Systemen, die diesen Befehl unterstützen.

Die Installation

  1. Man sollte sicherstellen, das man die neueste Version von mpatrol installiert.
  2. Archiv entpacken.
  3. Wenn man will, so kann man die entpackten Dateien mit dem CHECKSUM Programm testen. Hierfür braucht man allerdings zusätzlich noch md5sum.
  4. Jetzt muss man in das build Verzeichnis wechseln und dort in das jeweilige Betriebssystem Unterverzeichnis. Möglich sind die Betriebssysteme Amiga, Netware, Unix und Windows.
  5. Dort muss man nun das Makefile überprüfen. Verschiedene Betriebssysteme nutzen zum Beispiel verschiedene Compiler (cc oder gcc) oder verschiedene ar derivate. Dabei haben die aufgeführten Macro's die folgenden Bedeutungen:
    CC Enthällt den zu verwendenden Compiler. (gcc, cc)
    AR Das zu verwendenden ar commando. (ar)
    LD Das tool mit welchen die Shared libraries gebaut werden sollen. (ld)
    CFLAGS Specifiziert die Compiler Optionen. (-c ...)
    SFLAGS Die Optionen die beim bauen der Shared libraies zum Compiler mit übergeben werden sollen.
    TFLAGS Optionen die dem Compiler beim bauen der Thread sicheren library mit übergeben werden sollen.
    OFLAGS Die optimierungs Optionen vom Compiler.
  6. Mit dem make commando kann man als nächstes die mpatrol Bibliotheck übersetzen. Dabei sind folgende Pseudoziele für make definiert:
    all Baut alle möglichen library kombinationen für das System.
    clean Löscht alle relevanten objeckt Dateien von dem aktuellem Verzeichnis. Lässt allerdings die Bibliothecken bestehen.
    clobber Löscht alle Libraies vom aktuellem Verzeichnis.
    lint Auf manchen Unix systemen produziert dieses Ziel ein lint kommando das zusammen mit mpatrol arbeitet.
  7. Wenn mpatrol mit insure zusammen arbeiten soll, muss vor dem übersetzen das MP_INUSE_SUPPORT Macro in den CFLAGS definiert werden. Wichtig: In diesem fall müssen alle mit mpatrol zu testende Programme zusätzlich mit der Insure++ runtime library übersetzt werden.
  8. Nun müssen die erstellten Bibliotheken irgendwo hin kopiert werden, wo sie der Linker finden kann. Üblicherweise ist das /usr/lib. Achtung: Links müssen natürlich auch mit kopiert werden.
    Hat man das gemacht ist es oft sinnig ein Programm wie ldconfig zu starten, so dass das System weiss, das es die neuen Libraries gibt.
    Kopiert man die Libraries nicht an eine andere Stelle oder möchte man diese an einen nicht Standardmässigen Platz verschieben, so muss man natürlich auch die LD_LIBRARY_PATH Variable dementsprechend umsetzen.
  9. Die Programme mpatrol, mprof, mptrace und mleak welche in dem Verzeichnis gebaut wurden, sollten nun in das eigene binär Verzeichnis kopiert werden. Empfehlenswert sind ausserdem noch die Programme mpsym, mpedit und hexwords, wenn das System eine Bourne shell unterstützt.
  10. Ein Verzeichnis höher (tools) entällt eine menge Header dateien. Diese Dateien sollten alle in das locale include Verzeichnis mpatrol kopiert werden. Das hier angesprochene mpatrol Verzeichnis im include pfad muss hierfür natürlich erst angelegt werden.
  11. Nur für Unix:
    Im man Verzeichnis kann man sich nun die Manual pages von mpatrol in sein eigenes man Verzeichnis kopieren.

Das doc Verzeichnis (eine Ebene höher) entällt eine ausführliche englische Dokumentation zu mpatrol.

Alternativ zu den oben genannten Installationsschritten, gibt es auch die Möglichkeit eines der in pkg enthaltenen Packete zu installieren. Insgesamt sind es 4 verschiedene Formate, die dort angeboten werden, und die Installation um einiges erleichtern können.

Einbinden der Bibliothek

Die folgenden Schritte erklären wie man seine Programme mit mpatrol testen kann. Sie sind in der Reihenfolge der am source code erforderlichen Änderrungen aufgelistet, so dass der letzte Schritt ein komplettes neu übersetzen erfordert.

  1. Dieser Schritt ist momentan nur auf einigen wenigen Plattformen verfügbar (DYNIX/ptx, FreeBSD, IRIX, Linux, NetBSD, OpenBSD, Solaris, auf neueren Tru64 sowie auf DG/UX 4.2MU07 und neueren Systemen, welche das LD_RELOAD feature unterstützen.

    Wenn das Programm dynamisch zur std. C - Bibliothek (libc.so) gelinkt wurde dann kann man die --dynamic Option beim mpatrol Befehl verwenden, um die Speicher allocierenden und freigebenden Aufrufe, zur Laufzeit, ohne das Programm neu linken zu müssen, zu überschreiben (was zum testen mit mpatrol ja umbedingt erforderlich ist). Handelt es sich um ein Programm das Threads nutzt, so muss allerdings in diesem Fall zusätzlich noch die --thread Option mit angegeben werden.

    Beispiel:
    Nehmen wir einmal an das wir ein Binärprogramm testproc testen wollen. Dazu muss man also den Befehl: "mpatrol --dynamic ./testproc -i file" ausführen und das Programm starten. Die nach dem beenden des Programmes erstellte log- Datei wird standardmässig mpatrol.<procid>.log genannt, wobei <progid> durch die jeweilige Process ID des gestartetten Programms ersetzt wird. Existiert diese Datei nach dem Beenden von testproc nicht, so unterstützt das Betriebssystem wahrscheinlich die LD_RELOAD funktionalität nicht oder man hat sich irgendwo vertan. Im ersteren Falle sollte man sich auf die nächste Möglichkeit mpatrol einzubinden konzentrieren.
  2. Dieser Schritt wird momentan nur von UNIX und Windows (und unter AmigaOS mit gcc) unterstützt.

    Es sollte möglich sein mpatrol zu berreits existierenden Object Dateien hinzu zu linken. Ein erneutes übersetzen der Sourcen ist dabei also nicht erforderlich. Beachtet werden sollte hier allerdings, das dieser Schritt nur Sinn macht, wenn das Betriebsystem einen "stack trace" zulässt. Tut es das nicht, so sind die Informationen, die mpatrol bieten kann wahrscheinlich sehr eingeschräkt und dadurch weniger hilfreich.
  3. Die nun folgenden Schritte setzen immer ein erneutes übersetzen, zumindest einiger der sourcen die getestet werden sollen, vorraus.

    Der erste Schritt ist dabei allerdings nur verfügbar, wenn man den gcc verwendet. Dort ist es nämlich möglich die -fcheck-memory-usage Option mit beim übersetzen anzugeben. Diese Option endeckt zum Beispiel den Fehler das ein Process nicht initialisierten Speicher auswertet. Auch deckt die Option eine Reichweitenüberprüfung mit ab. Ein Seiteneffect mit dieser eingeschalteter Option ist allerdings, dass das Pragramm deutlich langsamer ausgeführt werden wird. Genau wie eben, muss die mpatrol Bibliothek natürlich auch wieder mit beim linken eingebunden werden.
  4. Dieser Schritt ist von Vorteil, wenn man schon so eine waage Idee hat, in welcher Datei der vermeitliche Speicherfehler stecken könnte. Dort bindet man dann die mpatrol.h Header Datei mit ein und übersetzt diese Datei neu. Nun bindet man die übersetzte Datei mitsamt mpatrol zum Process und startet diesen. Nach dem beenden kann man dann die log- Datei wie gewohnt auswerten. Achtung: Diese Methode eignet sich nur dann, wenn man weiss, wo der Fehler verborgen sein könnte. Auch muss man sehr genau mit dem Verteilen der mpatrol.h Headerdatei auf die sourcen sein. So drückt sich zum Beispiel ein "ungesehenes" free in der lod- Datei als Memory leak aus.
  5. Hierbei ist ein komplettes neu übersetzen aller sourcen notwendig. Ausserdem muss in jeder Datei die mpatrol.h Headerdatei mit eingebunden werden. Dieser Schritt dauert also am längesten, obgleich viele compiler das einbinden einer Header Datei auf der Kommandozeile erlauben. So erlaubt der gcc zum Beispliel das einbinden mit der Option -include <file>.

    Beispiel:
    gcc -include /usr/local/include/mpatrol.h -c test.c

Es wird empfohlen beim übersetzen symbol informationen mit in das Ausführbare Programm mit ein zu binden. Dadurch ist es dann leichter möglich den Funktionsfluss mit zu verfolgen und im Falle eines core's diesen zu debuggen.

Wie auch immer man mpatrol nun mit in sein Programm einbindet und egal wie lange es dauert bis es das erste mal funktioniert mit mpatrol. Sicher ist in jedem Fall das man mit einem finden aller nur erdenklichen Fehler die man auf dem Heap so machen kann, belohnt wird.

MPATROL_OPTIONS

Die meisten Eigenschaften der Bibliothek können mit der Umgebungsvariablen MPATROL_OPTIONS kontrolliert werden. Die Variable kann dabei die weiter unten beschriebenen Optionen, komma separiert, enthalten.

    DEFALIGN
    Bekommt man beim laufen lassen des Programms, welches man zur mpatrol Bibliothek gelinkt hat, einen Bus error, so sollte man den Wert dieser Option etwas höher setzen. Standartmässig versucht mpatrol sich am kleinstmöglichen Addressraum auszurichten. Allerdings wird dies oft durch den Compiler beeinflusst. Wie auch immer kann man mit dieser Option die Datenausrichtung manuell um die angegebene anzahl Bytes verschieben. Dabei sollte die angegebene Zahl ein vielfaches von zwei und nicht grösser als die page-size vom System sein.
    NOPROTECT
    Auf Systemen, welche virtuellen Arbeitsspeicher zur verfügung stellen, wird die Bibliothek versuchen diesen mit einem Schreibschutz, während der Ausführung des Processes, zu versehen. Das macht es dann sehr schwer für den Process Daten der Bibliothek zu überschreiben. Wie auch immer ist das auf- und abbauen des Schutzes ein overhead den man vielleicht abschalten möchte. Ist diese Option also eingeschaltet, so wird der Schutz ausgeschaltet. Auf Systemen die keinen virtuellen Arbeitsspeicher unterützen, wird diese Option ignoriert.
    SAFESIGNALS
    Da manche Bibliotheksfunktionen nicht gegen asynchron auftretende Signale gesichert sind, kann man mit diesem Schalter diese Funktionen während ihrer ausführung absichern. Es ist allerdings vorsicht dabei geboten, da es schwierig sein dürfte, ein anscheinend stehendes Programm, zum Beispiel mit Srg-C, abzubrechen.
    CHECKFORK
    Unter UNIX kann der Systemaufruf fork zusammen mit dem darauf folgendem Aufruf exec zu erheblichen Problemen führen. Der Grund dafür ist, dass ein Kindprocess alle von seinem Vater angeforderten Speicher und Dateizeiger erbt. Er erbt also unter anderem auch die Logdatei. Dies führt dann meistens zu Verwirrungen bei der Auswertung der Meldungen in der Logdatei, da dort dann von zwei Processen die Ausgaben landen. Mit dieser Option hat man nun jedoch die Möglichkeit mpatrol sicherstellen zu lassen, um welchen Process es sich handelt, der eine Ausgabe absetzen möchte. Die Bibliothek wird dann für den Kindprocess ein eigenes log anlegen. Diese Option muss allerdings in Kombination mit einem Aufruf von __mp_reinit() beim erstellen des Childs einher gehen.
Copyright (c) 2001-2002 by: Gerrit Bruchhäuser