[Xorp-hackers] Runtime diagnostics and callbacks in backtraces

[Ben Greear]

On 11/18/2009 06:58 AM, Bruce Simpson wrote:
> Ben Greear wrote:
>>
>> 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.
>
> I'm confused why preserving the XRL would make a difference here.

I'd like to know what triggered a chain of events leading up to
an assert/crash/whatever.  It's probably a timer (which could
store it's __LINE__ and __FILE__ (and/or other debug info)
on creation, or it's the result of some request from outside (XRL).

>> 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.
>
> Have you looked at DEBUG_CALLBACKS, which already does some of this?
>
> The problem with it is that it doesn't have much fine granularity -- if
> you turn it on for everything, the code will wedge.
> It's also a bit invasive for production use.

If you can't turn it on for production, then it's worthless for getting
bug reports out of the field.  If we're only storing strings in objects,
and only writing them out to logs when a problem actually occurs, it shouldn't
be _too_ much overhead.


> However, asking for asynchronous code to be made linear, is pretty much
> calling for a design change which won't happen. The whole XORP
> architecture is designed to run in an event-driven manner. In all of the
> code that I've read, I haven't seen any which was async when it didn't
> need to be.

Maybe this is the case, but from my grubbing around in rtr-mgr, it seems
like things could be made more straight-forward in many cases.  No
need to worry about this now, though..I'm not planning to hack on this
anytime soon.


>> 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.
>
> It might interest you to know that the Router Manager is not being used
> in the commercial XORP product. Although this has more to do with how
> it's being deployed.

I have no knowledge of how commercial XORP is supposed to work.  Until
I see actual code being merged back into the open project, I'm going to
assume commercial xorp has forked and gone away.

As for the rest of the discussion, I'm trying to hold off on any un-needed
xorp coding until you get your changes merged.  Hopefully after that we
can merge at least some of my tree upstream.  And, after _that_, maybe
I'll have time and interest for hacking on callbacks, ref-ptrs and such.

Until then, I'm not doing much good by commenting more...

Thanks,
Ben

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