[Xorp-users] xorp_rib SEGV when removing interface while using OSPF.

Ben Greear greearb at candelatech.com
Sat Sep 22 15:59:19 PDT 2007


While testing removing interfaces & OSPF, I get a core from rib_xorp.  
The backtrace shows that
the net object has a _vif that is bad memory (ie, already deleted as far 
as I can tell.)

I believe it might be because of this code in rib.cc.  It is cleaning 
out all of the
'directly connected' routes, but maybe it is not cleaning up OSPF routes?

Since we are deleting the vif object, I think we should notify all 
tables that the
vif is being deleted and have it delete any route that references the 
vif, regardless
of what IP the route is.  Otherwise, stale memory will be referenced 
next time
something messes with the routes on the dead interface.

int
RIB<A>::delete_vif(const string& vifname)
{
    debug_msg("RIB::delete_vif: %s\n", vifname.c_str());
    map<string, Vif>::iterator vi = _vifs.find(vifname);
    if (vi == _vifs.end()) {
        return XORP_ERROR;
    }
    Vif& vif = vi->second;

    if (vif.is_underlying_vif_up()) {
        //
        // Delete the directly connected routes associated with this vif
        //
        list<VifAddr>::const_iterator ai;
        for (ai = vif.addr_list().begin(); ai != vif.addr_list().end(); 
++ai) {
            if (ai->addr().af() != A::af())
                continue;

            IPNet<A> subnet_addr;
            A peer_addr;
            ai->subnet_addr().get(subnet_addr);
            ai->peer_addr().get(peer_addr);
            delete_connected_route(vif, subnet_addr, peer_addr);
        }
    }

    _vifs.erase(vi);
    return XORP_OK;
}

Here's the backtrace.  _vif is corrupted by frame 11.

#0  0x473b680f in std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6
#1  0x080b81b4 in DeleteRoute (this=0x82b6020, parent=0x82aca28, 
ipr=@0x82b6bf0) at redist_xrl.cc:236
#2  0x080b82a0 in DeleteTransactionRoute (this=0x82b6020, 
parent=0x82aca28, ipr=@0x82b6bf0) at redist_xrl.cc:618
#3  0x080b9fbd in RedistTransactionXrlOutput<IPv4>::delete_route 
(this=0x82aca28, ipr=@0x82b6bf0) at redist_xrl.cc:1062
#4  0x08057e23 in Redistributor<IPv4>::RedistEventInterface::did_delete 
(this=0x82ac3d8, ipr=@0x82b6bf0) at rt_tab_redist.cc:294
#5  0x08059768 in RedistTable<IPv4>::delete_route (this=0x82a3c20, 
r=0x82b6bf0, caller=0x82a3bb0) at rt_tab_redist.cc:441
#6  0x080a6a77 in PolicyRedistTable<IPv4>::delete_route (this=0x82a3bb0, 
route=0x82b6bf0, caller=0x82a3b70) at rt_tab_pol_redist.cc:101
#7  0x080ad732 in RegisterTable<IPv4>::delete_route (this=0x82a3b70, 
route=0x82b6bf0, caller=0x82b5ce0) at rt_tab_register.cc:271
#8  0x0809bcf2 in MergedTable<IPv4>::delete_route (this=0x82b5ce0, 
route=0x82b6bf0, caller=0x82b6bd8) at rt_tab_merged.cc:109
#9  0x0809bcf2 in MergedTable<IPv4>::delete_route (this=0x82b6bd8, 
route=0x82b6bf0, caller=0x82b5f20) at rt_tab_merged.cc:109
#10 0x080597e1 in RedistTable<IPv4>::delete_route (this=0x82b5f20, 
r=0x82b6bf0, caller=0x82b60d0) at rt_tab_redist.cc:445
#11 0x0809f470 in OriginTable<IPv4>::delete_route (this=0x82b60d0, 
net=@0x82b1200) at rt_tab_origin.cc:131
#12 0x08086604 in RIB<IPv4>::delete_route (this=0xbfdac034, 
tablename=@0x82b5ea0, net=@0x82b1200) at rib.cc:878
#13 0x08066379 in XrlRibTarget::rib_0_1_delete_route4 (this=0xbfdac3d8, 
protocol=@0x82b5ea0, unicast=@0x82b6a7c, multicast=@0x82b1224,
    network=@0x82b1200) at xrl_target.cc:581
#14 0x0811c335 in XrlRibTargetBase::handle_rib_0_1_delete_route4 
(this=0xbfdac3d8, xa_inputs=@0xbfda3eac) at rib_base.cc:855
#15 0x0811d203 in XorpMemberCallback2B0<XrlCmdError const, 
XrlRibTargetBase, XrlArgs const&, XrlArgs*>::dispatch (this=0x829f1b0,
    a1=@0xbfda3eac, a2=0xbfda3e90) at ../../libxorp/callback_nodebug.hh:4615
#16 0x08190339 in XrlCmdEntry::dispatch (this=0x829f204, 
inputs=@0xbfda3eac, outputs=0xbfda3e90) at xrl_cmd_map.hh:37
#17 0x08196f5a in XrlDispatcher::dispatch_xrl (this=0xbfdac638, 
method_name=@0xbfda3e20, inputs=@0xbfda3eac, outputs=@0xbfda3e90)
    at xrl_dispatcher.cc:60
...
(gdb) print *found->_vif
$9 = {_vptr.Vif = 0x4d0a322e, _name = {static npos = 4294967295,
    _M_dataplus = {<std::allocator<char>> = 
{<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
      _M_p = 0x79546773 <Address 0x79546773 out of bounds>}}, _ifname = 
{static npos = 4294967295,
    _M_dataplus = {<std::allocator<char>> = 
{<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
      _M_p = 0x78206570 <Address 0x78206570 out of bounds>}}, _pif_index 
= 1902465802, _vif_index = 840986446, _is_pim_register = 55,
  _is_p2p = 49, _is_loopback = 55, _is_discard = 10, _is_unreachable = 
77, _is_multicast_capable = 115, _is_broadcast_capable = 103,
  _is_underlying_vif_up = 68, _mtu = 543257697, _addr_list = 
{<std::_List_base<VifAddr,std::allocator<VifAddr> >> = {
      _M_impl = {<std::allocator<std::_List_node<VifAddr> >> = 
{<__gnu_cxx::new_allocator<std::_List_node<VifAddr> >> = {<No data 
fields>}, <No data fields>}, _M_node = {_M_next = 0x646e6966, _M_prev = 
0x2f3a7265}}}, <No data fields>}}
(gdb)

Thanks,
Ben

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




More information about the Xorp-users mailing list