[Ndn-interest] NLSR dumping core... in nlsr::SyncLogicHandler::publishRoutingUpdate
Anil Jangam
anilj.mailing at gmail.com
Sun Mar 15 18:53:35 PDT 2015
Hi,
I have built a three node setup to test the NLSR functionality. In the
neighborhood configuration, do we have to explicitly configure the port
number?
on Router-1 (ndnr1) the configuration is as follows.
....
; lsa-refresh-time is the time in seconds, after which router will
refresh its LSAs
lsa-refresh-time 240 ; default value 1800. Valid values 240-7200
....
....
hello-interval 30 ; interest sending interval in
seconds. Default value 60
; valid values 30-90
....
neighbor
{
name /ndn/fj/ndnhost2/%C1.Router/icn/ndnr2 ; name prefix of the
neighbor router consists
; of network, site-name and
router-name
face-uri udp://133.164.60.158:6060 ; face uri of the face
connected to the neighbor
link-cost 30 ; cost of the connecting
link to neighbor
}
neighbor
{
name /ndn/fj/ndnhost4/%C1.Router/icn/ndnr4 ; name prefix of the
neighbor router consists
; of network, site-name and
router-name
face-uri udp://133.164.60.156:6060 ; face uri of the face
connected to the neighbor
link-cost 25 ; cost of the connecting link
to neighbor
}
I see 8 set of INFO message exchanges (30 seconds hello interval) between
all three router nodes. However at the end of 8th set, all three NLSR
processes crashes at the same time!!
I presume this is because something wrong happening when LSA refresh is
being done (LSA refresh is 240 secs). I am not sure whats wrong, if any, in
my configuration.
Questions:
- Do we have to configure the port number in the face-uri value?
- I presume this port number must be different than the NFD port number
(6363).
Some of the other observations:
- I do not think we have to explicitly configure the FIB by registering
the prefix. I actually did it and observed that those entries are cleared
from FIB at run-time. Is this a valid behavior?
- I am not sure if we have to explicitly add the FACES by creating them
on NFD. I actually did create them, but observed that they are
removed/cleared at run-time. Is this a valid behavior?
I have attached the stack trace of the core dump file for further analysis.
Kindly please comment.
/anil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150315/997ac8db/attachment.html>
-------------- next part --------------
ndnusr1 at ndnhost1:~/sandbox/NLSR$ gdb build/bin/nlsr core
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build/bin/nlsr...done.
[New LWP 21359]
[New LWP 21370]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./build/bin/nlsr -f nlsr.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 Sync::SyncSocket::publishData (this=0x0, prefix=..., session=session at entry=0,
buf=buf at entry=0x23add48 "NoData", len=len at entry=6, freshness=freshness at entry=1000,
seq=seq at entry=41781477507102) at ../nsync/sync-socket.cc:72
72 m_face->getIoService().post(bind(&SyncSocket::publishDataInternal, this,
(gdb) where
#0 Sync::SyncSocket::publishData (this=0x0, prefix=..., session=session at entry=0,
buf=buf at entry=0x23add48 "NoData", len=len at entry=6, freshness=freshness at entry=1000,
seq=seq at entry=41781477507102) at ../nsync/sync-socket.cc:72
#1 0x000000000045a3e0 in nlsr::SyncLogicHandler::publishSyncUpdate (this=0x7fff39a218a0, updatePrefix=...,
seqNo=41781477507102) at ../src/communication/sync-logic-handler.cpp:278
#2 0x000000000045a5ab in nlsr::SyncLogicHandler::publishRoutingUpdate (this=<optimized out>)
at ../src/communication/sync-logic-handler.cpp:259
#3 0x0000000000478f6f in nlsr::Lsdb::exprireOrRefreshNameLsa (this=0x7fff39a21740, lsaKey=...,
seqNo=<optimized out>) at ../src/lsdb.cpp:654
#4 0x0000000000550772 in operator() (this=0x7fff39a20ee0) at /usr/include/c++/4.8/functional:2464
#5 ndn::util::scheduler::Scheduler::onEvent (this=0x7fff39a21310, error=...) at ../src/util/scheduler.cpp:182
#6 0x0000000000550990 in operator()<const boost::system::error_code&, void> (__object=<optimized out>,
this=0x7fff39a20f90) at /usr/include/c++/4.8/functional:601
#7 __call<void, boost::system::error_code const&, 0ul, 1ul> (__args=<optimized out>, this=0x7fff39a20f90)
at /usr/include/c++/4.8/functional:1296
#8 operator()<const boost::system::error_code&, void> (this=0x7fff39a20f90)
at /usr/include/c++/4.8/functional:1355
#9 operator() (this=0x7fff39a20f90) at /usr/local/include/boost/asio/detail/bind_handler.hpp:46
#10 asio_handler_invoke<boost::asio::detail::binder1<std::_Bind<std::_Mem_fn<void (ndn::util::scheduler::Scheduler::*)(const boost::system::error_code&)>(ndn::util::scheduler::Scheduler*, std::_Placeholder<1>)>, boost::system::error_code> > (
function=<error reading variable: access outside bounds of object referenced via synthetic pointer>)
at /usr/local/include/boost/asio/handler_invoke_hook.hpp:64
#11 invoke<boost::asio::detail::binder1<std::_Bind<std::_Mem_fn<void (ndn::util::scheduler::Scheduler::*)(const boost::system::error_code&)>(ndn::util::scheduler::Scheduler*, std::_Placeholder<1>)>, boost::system::error_code>, std::_Bind<std::_Mem_fn<void (ndn::util::scheduler::Scheduler::*)(const boost::system::error_code&)>(ndn::util::scheduler::Scheduler*, std::_Placeholder<1>)> > (context=..., function=...)
at /usr/local/include/boost/asio/detail/handler_invoke_helpers.hpp:39
#12 boost::asio::detail::wait_handler<std::_Bind<std::_Mem_fn<void (ndn::util::scheduler::Scheduler::*)(boost::system::error_code const&)> (ndn::util::scheduler::Scheduler*, std::_Placeholder<1>)> >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) (owner=0x2371a00, base=0x23a60a0) at /usr/local/include/boost/asio/detail/wait_handler.hpp:69
#13 0x00000000004d88bf in complete (bytes_transferred=<optimized out>, ec=..., owner=..., this=0x23a60a0)
at /usr/local/include/boost/asio/detail/task_io_service_operation.hpp:37
#14 do_run_one (ec=..., this_thread=..., lock=..., this=0x2371a00)
at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:412
#15 boost::asio::detail::task_io_service::run (this=0x2371a00, ec=...)
at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:153
---Type <return> to continue, or q <return> to quit---
#16 0x00000000004d4255 in run (this=0x7fff39a21260) at /usr/local/include/boost/asio/impl/io_service.ipp:59
#17 ndn::Face::processEvents (this=0x7fff39a212d0, timeout=..., keepThread=keepThread at entry=false)
at ../src/face.cpp:435
#18 0x0000000000482889 in nlsr::Nlsr::startEventLoop (this=this at entry=0x7fff39a21390) at ../src/nlsr.cpp:296
#19 0x00000000004403f1 in nlsr::main (argc=3, argv=<optimized out>) at ../src/main.cpp:87
#20 0x00007fc678c87ec5 in __libc_start_main (main=0x4406f0 <main(int32_t, char**)>, argc=3, argv=0x7fff39a21e78,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff39a21e68)
at libc-start.c:287
#21 0x000000000044fd92 in _start ()
(gdb)
More information about the Ndn-interest
mailing list