Actions
Bug #5297
closedPotential race condition in PcapHelper from ifconfig up/down
Start date:
Due date:
% Done:
100%
Estimated time:
Description
In Mini-NDN experiments which frequently make use of ifconfig up/down with permanent faces, we have observed the following NFD crash frequently but inconsistently:
std::exception::what: pcap_setfilter: recv failed when changing filter: Network is down
===== Stacktrace =====
0# nfd::face::PcapHelper::setPacketFilter(char const*) const [clone .cold] at ../daemon/face/pcap-helper.cpp:130
1# nfd::face::MulticastEthernetTransport::MulticastEthernetTransport(ndn::net::NetworkInterface const&, ndn::ethernet::Address const&, ndn::nfd::LinkType) at ../daemon/face/multicast-ethernet-transport.cpp:78
2# nfd::face::EthernetFactory::createMulticastFace(ndn::net::NetworkInterface const&, ndn::ethernet::Address const&) at ../daemon/face/ethernet-factory.cpp:254
3# nfd::face::EthernetFactory::applyMcastConfigToNetif(ndn::net::NetworkInterface const&) at ../daemon/face/ethernet-factory.cpp:334
4# nfd::face::EthernetFactory::applyConfig(nfd::face::FaceSystem::ConfigContext const&) at ../daemon/face/ethernet-factory.cpp:367
5# nfd::face::EthernetFactory::doProcessConfig(boost::optional<boost::property_tree::basic_ptree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&>, nfd::face::FaceSystem::ConfigContext&) at ../daemon/face/ethernet-factory.cpp:123
6# nfd::face::ProtocolFactory::processConfig(boost::optional<boost::property_tree::basic_ptree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&>, nfd::face::FaceSystem::ConfigContext&) at ../daemon/face/protocol-factory.cpp:76
7# nfd::face::FaceSystem::processConfig(boost::property_tree::basic_ptree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at ../daemon/face/face-system.cpp:124
8# nfd::ConfigFile::process(bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const at ../daemon/common/config-file.cpp:127
9# nfd::ConfigFile::parse(std::istream&, bool, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at ../daemon/common/config-file.cpp:113
10# nfd::ConfigFile::parse(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) at ../daemon/common/config-file.cpp:91
11# nfd::Nfd::reloadConfigFileFaceSection() at ../daemon/nfd.cpp:208
12# std::_Function_handler<void (), nfd::Nfd::initialize()::{lambda()#1}::operator()() const::{lambda()#1}>::_M_invoke(std::_Any_data const&) at /usr/include/c++/9/bits/std_function.h:302
13# ndn::scheduler::Scheduler::executeEvent(boost::system::error_code const&) at ../ndn-cxx/util/scheduler.cpp:150
14# boost::asio::detail::wait_handler<ndn::scheduler::Scheduler::scheduleNext()::{lambda(auto:1 const&)#1}, boost::asio::detail::io_object_executor<boost::asio::executor> >::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) at /usr/include/boost/asio/detail/wait_handler.hpp:71
15# boost::asio::detail::scheduler::run(boost::system::error_code&) at /usr/include/boost/asio/detail/impl/scheduler.ipp:200
16# nfd::NfdRunner::run() at ../daemon/main.cpp:157
17# main at ../daemon/main.cpp:339
18# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
19# _start in /usr/local/bin/nfd
======================
This crash seems to generally be more frequent on more resource constrained systems, however it's been difficult to replicate consistently. @Davide Pesavento has suggested this may be a race condition caused when an interface is brought up or down.
Actions