Wenn wir ein hochwertiges Produkt unserer Oracle BRM Software zu entwickeln, müssen wir einige Anforderungen an unseren Entwicklungsprozess erfüllen. Es ist besonders wichtig, gute Test- und Debugging-Techniken in unseren Entwicklungsprozess einzubauen.
Testen ist ein Prozess, bei dem Bugs oder Fehler in einem Softwareprodukt aufgespürt werden. Dieser Prozess wird manuell von einem Tester durchgeführt oder kann automatisiert werden.
Fehlersuche ist der Prozess der Suche und Behebung von Fehlern oder Problemen in einem Computerprogramm, die den korrekten Betrieb von Computersoftware oder eines Systems verhindern. Im Grunde handelt es sich um einen Prozess zur Behebung der in der Testphase gefundenen Fehler. Der Programmierer oder Entwickler ist für das Debugging verantwortlich und es kann nicht automatisiert werden.
Inhaltsverzeichnis
Debuggen von benutzerdefiniertem Code für Oracle BRM-Richtlinien-Opcodes
Beim Anpassen von Richtlinien-Opcodes in Oracle BRM Es ist oft notwendig, einen Code zu debuggen, um mögliche Fehler zu finden oder das Verhalten des Codes zu analysieren. Einige grundlegende Analysen können mit der Protokollierung einiger Debug-Meldungen und der Analyse von Protokollen durchgeführt werden, aber eine viel fortgeschrittenere und leistungsfähigere Methode ist die Verwendung eines separaten Tools - des Debuggers. In diesem Artikel werden wir uns ansehen, wie wir den Open-Source-Debugger GDB verwenden können, um einen Oracle BRM cm-Prozess zu debuggen, der auch einige benutzerdefinierte Codes ausführt (siehe das Bild unten).
GDB ist ein Open-Source-Debugger, der viele fortschrittliche und leistungsstarke Tools zum Analysieren und Debuggen unseres Codes bietet. Einige der grundlegenden Funktionen von GDB sind Haltepunkte (bedingt/unbedingt), Watches, Back Traces und inkrementelle Codeausführung. Sie können natürlich auch Variablenwerte anzeigen und ändern und verschiedene Funktionen aufrufen. Sehen wir uns nun an, wie wir GDB mit cm process in der Praxis verwenden.
Fehlersuche in der Praxis
Zunächst müssen wir eine PID für unseren CM-Prozess ermitteln:
ps x
Suchen Sie die PID des CM-Prozesses und verwenden Sie sie, um mit GDB eine Verbindung zu diesem Prozess herzustellen:
gdb cm
Jetzt öffnet sich die GDB-Shell, in der wir verschiedene Befehle ausführen können, die GDB unterstützt. Jede neue Verbindung, die zum CM aufgebaut wird, führt dazu, dass ein neuer CM-Kinderprozess vom übergeordneten CM gestartet wird. Wir möchten, dass GDB auch diese Kindprozesse verfolgt. Führen Sie den folgenden Befehl in der GDB-Shell aus:
(gdb) setze follow-fork-mode kind
Je nach Ihren Bedürfnissen können Sie auch die Befehle detach-on-fork und attach verwenden. Lassen Sie uns nun einen Haltepunkt für eine Policy-Opcode-Implementierung setzen, wie im folgenden Beispiel:
(gdb) break fm_act_pol_post_reauthorize.c:192
Wenn wir nun die Ausführung von Policy-Opcodes auslösen, wird diese durch einen Haltepunkt unterbrochen (oder sogar schon vorher benachrichtigt, dass ein neues Kind erzeugt wurde). Mit den Befehlen next (Abk. n) oder step können wir dann den Codefluss Schritt für Schritt verfolgen. Wenn wir an einem Variablenwert interessiert sind, können wir ihn mit ausgeben:
Wir verfügen auch über viele weitere fortgeschrittene und leistungsstarke Funktionen, die in der GDB-Dokumentation und der integrierten Hilfe ausführlich beschrieben sind. Sie sind herzlich eingeladen, diese zu erforschen, um zu sehen, wie sie Ihnen helfen können.
