views:

394

answers:

4

I'm thinking about adding code to my application that would gather diagnostic information for later examination. Is there any C++ library created for such purpose? What I'm trying to do is similar to profiling, but it's not the same, because gathered data will be used more for debugging than profiling.

EDIT:
Platform: Linux
Diagnostic information to gather: information resulting from application logic, various asserts and statistics.

+2  A: 

I tend to use logging for this purpose. Log4cxx works like a charm.

Kieveli
Well simple logging is one solution, although it doesn't look like best approach for me. Resulting logs are large, because aggregation of gathered data is done at time of examination of logs. Also many things need to be done by hand, i.e. structures used to collect data have to be invented from the beginning. Maybe there is some framework that simplifies things?
+1  A: 

If debugging is what you're doing, perhaps use a debugger. GDB scripts are pretty easy to write up and use. Maintaining them in parallel to your code might be challenging.

Edit - Appending Annecdote:

The software I maintain includes a home-grown instrumentation system. Macros are used to queue log messages and configuration options control what classes of messages are logged and the level of detail to be logged. A thread processes the logging queue, flushing messages to file and rotating files as they become too large (which they commonly do). The system provides a lot of detail, but often all too often it provides huge files our support engineers must wade through for hours to find anything useful.

Now, I've only used GDB to diagnose bugs a few times, but for those issues it had a few nice advantages over the logging system. GDB scripting allowed me to gather new instrumentation data without adding new instrumentation lines and deploying a new build of my software to the client. GDB can generate messages from third-party libraries (needed to debug into openssl at one point). GDB adds no run-time impact to the software when not in use. GDB does a pretty good job of printing the contents of objects; the code-level logging system requires new macros to be written when new objects need to have their states logged.

One of the drawbacks was that the gdb scripts I generated had no explicit relationship to the source code; the source file and the gdb script were developed independently. Ideally, changes to the source file should impact and update the gdb script. One thought is to put specially-formatted comments in code and have a scripting language make a pass on the source files to generate the debugger script file for the source file. Finally, have the makefile execute this script during the build cycle.

It's a fun exercise to think about the potential of using GDB for this purpose, but I must admit that there are probably better code-level solutions out there.

veefu
A: 

If you execute your application in Linux, you can use "ulimit" to generate a core when your application crash (or assert(false), or kill -6 ), later, you can debug with gdb (gdb -c core_file binary_file) and analyze the stack.

Salu2.

PD. for profiling, use gprof

Miguel Angel
+2  A: 

You might also want to check out libcwd:

Libcwd is a thread-safe, full-featured debugging support library for C++ developers. It includes ostream-based debug output with custom debug channels and devices, powerful memory allocation debugging support, as well as run-time support for printing source file:line number information and demangled type names.

Also, another interesting logging library is pantheios:

Pantheios is an Open Source C/C++ Logging API library, offering an optimal combination of 100% type-safety, efficiency, genericity and extensibility. It is simple to use and extend, highly-portable (platform and compiler-independent) and, best of all, it upholds the C tradition of you only pay for what you use.

none