[Xorp-hackers] Potential null pointer dereference.

Pavlin Radoslavov pavlin at ICSI.Berkeley.EDU
Tue Mar 4 23:05:29 PST 2008


> > The reason those XLOG statements are FATAL is to capture bugs that
> > might be hiding somewhere else.
> > If you were able to trigger those statements, could you provide
> > instructions how to reproduce the problem so we can investigate it.
> 
> For a true lab scenario this would probably be
> the wanted behaviour, but for software that is
> supposed to be able to work in the real world it
> is probably not.

If we just ignore those fatal errors, you could end up with a
process that has wrong internal state.
So pick your poison: a coredump with state that might be useful for
us to locate and fix the problem or a process with probably
incorrect internals that might or might not be working properly but
is practically impossible to debug.

> One of the most interesting parts I've seen with
> IOS XR (Ciscos new operating system for the CRS-1)
> is the ability to track what all processes are
> doing all the time, so if a fault occurs, debug
> information is saved at all times, even though the
> administrator of the system has not asked of this.

What this information looks like: a backtrace-like info after a
crash or real time log messages for various events?

Thanks,
Pavlin

> This is very Service Providerisch ;), it'd be nice
> to see XORP have something like it.
> 
>   -K
> 
> -- 
> Kristian Larsson                                        KLL-RIPE
> Network Engineer & Peering Coordinator      SpriteLink [AS39525]
> +46 704 910401			              kll at spritelink.net
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers



More information about the Xorp-hackers mailing list