Re: [boost] Interest check: Boost.Debug

Subject: Re: [boost] Interest check: Boost.Debug
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2009-06-02 17:47:09

2009/6/2 Zachary Turner <divisortheory_at_[hidden]>

> In my spare time I have been working on a library to analyze debug
> information from a running program.  It either already does, or I would
> like
> to have it before I'm done, support all of the following (I'm sure there
> are
> plenty of other neat additions that I haven't thought of):
>

This sounds extremely useful, we've developed quite a bit of in-house
production code (unfortunately for Windows as well so can't help with
portability) and it helps a great deal in large-scale software.

>
> - Loading debug info either for the currently running executable or from an
> offline executable

Care to elaborate a bit, I don't follow exactly. How is this useful compared
to attaching a debugger?

>
> - Printing human readable stack traces from a running program

IMO getting a stack-trace really quick, and defer the print-out (using the
dbghelp on windows for instance) until the user requests it would be more
useful than printout only. Like:

boost::debug::stack_trace foo()
{
  return stack_trace();
]

boost::debug::stack_trace bar()
{
  return foo();
};

main()
{
  std::cout << bar();
}

It could then also be bundled together with boost::exception without a huge
performance impact at throw site, and without having the exception object
grow unhealthy big.

> - Dumping stack traces to a file in release mode. In this case it's usually
> just a dump of the entire stack in binary.

Where to dump the trace is better left to a logging library (there are two
submissions to boost atm I think) or to the choice of user.

>
> - Matching dumped stacks from step 3 to debug information offline to get
> post-mortem information.

Same as above.

> - Assuming symbol information is loaded either for the running program or
> an
> offline program, format a block of memory in a human readable format to
> print the structure of the memory (for example, display member values of a
> class with field names, given a block of memory representing an instance of
> the class)

Care to provide an example here?

>
> - launch process under a debugger and receive basic types of debugging
> notifications.
>

What kind of notifications are you referring to?

>
> That being said, is it worth it to tackle something like this or should I
> just not worry about the generality and keep working on it for personal use
> only?
>

It's always worth worrying about =)

I think the problem can be divided into:
1). Collect information (thread context, stack-frames, stack-size, memory
load and other useful diagnostics).
2). Output information (using a symbol engine for stack-trace, such as
dbghelp)
3). Support bundling with boost::exception, to allow for the useful feature
of easily dumping where from an exception was originally thrown, if a stack
trace was added to the exception by user.

I do not think it should provide a logging facility, since that's quite a
task by itself.

Regards,
Christian