> > > While merging my old patch set with the latest xorp tree, I believe
> > > I found a potential null pointer dereference. Here is my attempt
> > > at fixing it:
> > >
> > > [EMAIL PROTECTED] control_socket]$ cvs diff -u netlink_socket_utilities.cc
> > > Index: netlink_socket_utilities.cc
> > > ===================================================================
> > > RCS file:
> > > /cvs/xorp/fea/data_plane/control_socket/netlink_socket_utilities.cc,v
> > > retrieving revision 1.12
> > > diff -u -r1.12 netlink_socket_utilities.cc
> > > --- netlink_socket_utilities.cc 8 Jan 2008 23:30:09 -0000 1.12
> > > +++ netlink_socket_utilities.cc 26 Feb 2008 19:40:36 -0000
> > > @@ -332,9 +332,10 @@
> > > const IfTreeVif* vifp = iftree.find_vif(if_index);
> > > if (vifp == NULL) {
> > > if (! is_deleted) {
> > > - XLOG_FATAL("Could not find interface and vif for index
> > > %d",
> > > + XLOG_ERROR("Could not find interface and vif for index
> > > %d",
> > > if_index);
> > > }
> > > + return XORP_ERROR;
> > > }
> > > if_name = vifp->ifname();
> > > vif_name = vifp->vifname();
> > >
> >
> >
> > Here's another one:
> > [EMAIL PROTECTED] ifconfig]$ cvs diff -u ifconfig_parse_netlink_socket.cc
> > Index: ifconfig_parse_netlink_socket.cc
> > ===================================================================
> > RCS file:
> > /cvs/xorp/fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc,v
> > retrieving revision 1.17
> > diff -u -r1.17 ifconfig_parse_netlink_socket.cc
> > --- ifconfig_parse_netlink_socket.cc 21 Feb 2008 02:02:33 -0000 1.17
> > +++ ifconfig_parse_netlink_socket.cc 26 Feb 2008 20:06:18 -0000
> > @@ -603,7 +603,8 @@
> > //
> > return;
> > }
> > - XLOG_FATAL("Could not find vif with index %u in IfTree", if_index);
> > + XLOG_ERROR("Could not find vif with index %u in IfTree", if_index);
> > + return;
> > }
> > debug_msg("Address event on interface %s vif %s with interface index
> > %u\n",
> > vifp->ifname().c_str(), vifp->vifname().c_str(),
> >
>
> Ben,
>
> Did you see those FATAL/ERROR statements actually triggered when
> running XORP?
> 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.
Some update on the subject:
* The XLOG_FATAL() inside netlink_socket_utilities.cc might happen
because of a race condition. E.g., an interface was added and then
immediately deleted, but the processing of the addition of
the corresponding connected route was delayed.
Fixing this race condition requires serious refactoring of the
bottom of the FEA.
For the time being I am leaving the XLOG_FATAL() in place until
there is enough evidence and the issue is understood.
* The XLOG_FATAL() inside ifconfig_parse_netlink_socket.cc is more
mysterious, because it doesn't appear it should be triggered by a
race condition like the previous one.
Ben, if you can provide some backtraces from the above two
XLOG_FATAL() crashes this might help understanding the problems.
BTW, there was an independent bug regarding dereferencing a NULL
pointer in the first case, but I fixed that.
I also added some additional comments to the code to explain
each of the actions.
Thanks,
Pavlin
_______________________________________________
Xorp-hackers mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
