[Xorp-hackers] Runtime diagnostics and callbacks in backtraces

[Ben Greear]

On 11/17/2009 08:20 AM, Bruce Simpson wrote:


> These aren't really useful to us here; our problem is that of producing
> meaningful system diagnostics, when the router is deployed in the field.
> One answer to this might be to add explicit backtrace support which we
> can potentially ship in a production build.

If you just had the original XRL in text format and/or binary format,
you could use gdb and/or live error-handling code to print it out.  You
could post-process this manually or programatically to decode what
the XRL command is, for instance.

Given the current call chain, the backtrace is likely to stop at the
timer handler or task dispatcher, which still gives you no clue about
what actually created the timer or task.

> This is a very callback-specific problem.
>
> As you quite rightly pointed out originally, it's something which could
> potentially be solved with a first-class object, , i.e. instead of this:

A first-class object would let us easily add a __LINE__ and __FILE__ where it
was created at, for instance.  This could be printed out later with or without
fancy backtrace support in the toolchain.

But, what would be even better is to decrease the number of callbacks
and just process code in a linear manner and pass back correct
return codes and/or message strings.  Then the backtraces will
actually show the originator of the actions.

I wouldn't mind re-writing the router manager to do this more
to my liking, but I'll wait until you post your xorp-ipc rewrite
first.

> typedef XorpCallback2<const XrlCmdError, const XrlArgs&,
> XrlArgs*>::RefPtr XrlRecvCallback;
> try to do something like this:
> class XrlRecvCallback : public XorpCallback2<const XrlCmdError, const
> XrlArgs&, XrlArgs*>::RefPtr {}

That still has template and typedef shit all over it.  I really don't
think we should need templates for this, and a very few, if any,
typedefs.  With proper accounting for object ownership, we could probably get
rid of ref-ptrs w/out undue pain as well.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com