2009-05-27 3 views
3

Ich überlege, Code zu meiner Anwendung hinzuzufügen, die Diagnoseinformationen für eine spätere Untersuchung sammeln würde. Gibt es eine C++ - Bibliothek, die für diesen Zweck erstellt wurde? Was ich versuche, ist dem Profiling ähnlich, aber es ist nicht das Gleiche, da die gesammelten Daten eher zum Debuggen als zum Profiling verwendet werden.Instrumentation (Diagnose) -Bibliothek für C++

EDIT:
Plattform: Linux
Diagnoseinformationen zu sammeln: Informationen aus der Anwendungslogik führen, verschiedene behauptet und Statistiken.

+0

welche OS/Plattform? Welche Art von Diagnose? – Tim

Antwort

2

Sie auch libcwd überprüfen möchten:

Libcwd ist ein Thread-sichere, voll funktionsfähige Debugging-Unterstützung Bibliothek für C++ Entwickler.Es enthält ostream-basierte Debug-Ausgabe mit benutzerdefinierten Debug- Kanäle und Geräte, leistungsstarke Speicherzuweisung Debugging-Unterstützung, sowie als Laufzeitunterstützung für den Druck Quelldatei: Zeilennummer Informationen und entmagnetisierten Typnamen.

Auch eine weitere interessante Logging-Bibliothek ist pantheios:

Pantheios ist eine Open Source C/C++ Logging API-Bibliothek, die eine optimale Kombination von 100% Typ-Sicherheit, Effizienz, Generizität und Erweiterbarkeit bietet. Es ist einfach zu bedienen und zu erweitern, hoch-portabel (Plattform und Compiler-unabhängig) und, das Beste von allem, es hält die C-Tradition von Ihnen bezahlen nur für das, was Sie verwenden.

2

Ich neige dazu, Protokollierung für diesen Zweck zu verwenden. Log4cxx wirkt wie ein Zauber.

+0

Nun, einfaches Logging ist eine Lösung, obwohl es für mich nicht die beste Lösung ist. Die resultierenden Protokolle sind groß, da die gesammelten Daten zum Zeitpunkt der Prüfung der Protokolle gesammelt werden. Auch viele Dinge müssen von Hand gemacht werden, d. H. Strukturen, die zum Sammeln von Daten verwendet werden, müssen von Anfang an erfunden werden. Vielleicht gibt es einen Rahmen, der Dinge vereinfacht? –

1

Wenn Sie debuggen, verwenden Sie vielleicht einen Debugger. GDB-Skripte sind ziemlich einfach zu schreiben und zu verwenden. Es könnte eine Herausforderung sein, sie parallel zu Ihrem Code zu verwalten.

Bearbeiten - Anfügen Annecdote:

Die Software, die ich pflegen umfasst ein Instrumentensystem home-grown. Makros werden verwendet, um Protokollmeldungen in die Warteschlange zu stellen, und Konfigurationsoptionen steuern, welche Arten von Nachrichten protokolliert werden und welche Detailgenauigkeit protokolliert werden muss. Ein Thread verarbeitet die Protokollierungswarteschlange, löscht Nachrichten in Dateien und rotiert Dateien, wenn sie zu groß werden (was sie gewöhnlich tun). Das System bietet viele Details, aber oft genug stellt es allzu oft riesige Dateien bereit, die unsere Supporttechniker stundenlang durchsuchen müssen, um etwas Nützliches zu finden.

Jetzt habe ich GDB nur verwendet Bugs ein paar Mal zu diagnostizieren, aber für diese Probleme hatte es ein paar netten Vorteile gegenüber dem Logging-System. Dank GDB-Scripting konnte ich neue Instrumentierungsdaten sammeln, ohne neue Instrumentierungslinien hinzufügen und einen neuen Build meiner Software auf dem Client bereitstellen. GDB kann Nachrichten von Bibliotheken von Drittanbietern erzeugen (die zum Debuggen in openssl an einem bestimmten Punkt benötigt werden). GDB fügt der Software keine Auswirkungen auf die Laufzeit hinzu, wenn sie nicht verwendet wird. GDB macht einen ziemlich guten Job, den Inhalt von Objekten zu drucken; Das Protokollierungssystem auf Codeebene erfordert das Schreiben neuer Makros, wenn neue Objekte ihre Status protokollieren müssen.

Einer der Nachteile war, dass der GDB-Skripte Ich hatte keine explizite Beziehung zu dem Quellcode erzeugt; Die Quelldatei und das gdb-Skript wurden unabhängig voneinander entwickelt. Im Idealfall sollten Änderungen an der Quelldatei das gdb-Skript beeinflussen und aktualisieren. Ein Gedanke besteht darin, speziell formatierte Kommentare in Code zu schreiben und eine Skriptsprache zu verwenden, um die Quelldateien zu übergeben, um die Debugger-Skriptdatei für die Quelldatei zu generieren. Schließlich muss das Makefile dieses Skript während des Build-Zyklus ausführen.

Es ist eine nette Übung über das Potenzial zu denken GDB der Verwendung für diesen Zweck, aber ich muss zugeben, dass es da draußen wahrscheinlich bessere Code-Level-Lösungen sind.

0

Wenn Sie Ihre Anwendung in Linux ausführen, können Sie "ulimit" verwenden, um einen Kern beim Absturz Ihrer Anwendung (oder assert (false) oder kill -6) zu generieren. Später können Sie mit gdb debuggen (gdb -c core_file binary_file) und analysieren den Stack.

Salu2.

PD. Verwendung für die Profilerstellung, gprof