[Ns-bugs] [Bug 812] New: Assert when getting socket in RecvReply for AODV

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=812

           Summary: Assert when getting socket in RecvReply for AODV
           Product: ns-3
           Version: ns-3.7
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: routing
        AssignedTo: ns-bugs at isi.edu
        ReportedBy: kevjay at gmail.com
   Estimated Hours: 0.0


Created an attachment (id=759)
 --> (http://www.nsnam.org/bugzilla/attachment.cgi?id=759)
Script to show assert in RecvReply

I've applied the preliminary patch provided at
http://www.nsnam.org/bugzilla/show_bug.cgi?id=772, because I ran into
that problem early on.  When my load testing gets up to 40 non-mobile nodes, it
fails with the following at second 78 of the simulation for
NS_ASSERT (socket) in RecvReply:

assert failed. file=../src/routing/aodv/aodv-routing-protocol.cc, line=1131,
cond="socket"
[New Thread 0x2aaf0569a150 (LWP 25388)]

Program received signal SIGSEGV, Segmentation fault.
0x00002aaf04e84665 in ns3::aodv::RoutingProtocol::RecvReply (this=0xaf44070,
p={m_ptr = 0x7fffeecf2d80}, receiver={m_address = 167837976}, sender=
      {m_address = 167837954}) at
../src/routing/aodv/aodv-routing-protocol.cc:1131
1131      NS_ASSERT (socket);
(gdb) where
#0  0x00002aaf04e84665 in ns3::aodv::RoutingProtocol::RecvReply
(this=0xaf44070, p={m_ptr = 0x7fffeecf2d80}, receiver={m_address = 167837976},
sender=
      {m_address = 167837954}) at
../src/routing/aodv/aodv-routing-protocol.cc:1131
#1  0x00002aaf04e872a8 in ns3::aodv::RoutingProtocol::RecvAodv (this=0xaf44070,
socket={m_ptr = 0x7fffeecf2e20})
    at ../src/routing/aodv/aodv-routing-protocol.cc:748
#2  0x00002aaf04e968be in ns3::MemPtrCallbackImpl<ns3::aodv::RoutingProtocol*,
void (ns3::aodv::RoutingProtocol::*)(ns3::Ptr<ns3::Socket>), void,
ns3::Ptr<ns3::Socket>, ns3::empty, ns3::empty, ns3::empty, ns3::empty,
ns3::empty, ns3::empty, ns3::empty, ns3::empty>::operator() (this=0xaf67bf0,
a1=
      {m_ptr = 0x7fffeecf2e70}) at debug/ns3/callback.h:223
#3  0x00002aaf04bbb512 in ns3::Callback<void, ns3::Ptr<ns3::Socket>,
ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty,
ns3::empty, ns3::empty>::operator() (this=0xaf67ae8, a1={m_ptr =
0x7fffeecf2eb0}) at debug/ns3/callback.h:410
#4  0x00002aaf04bb7aed in ns3::Socket::NotifyDataRecv (this=0xaf67a80) at
../src/node/socket.cc:284
#5  0x00002aaf04c6045a in ns3::UdpSocketImpl::ForwardUp (this=0xaf67a80,
packet={m_ptr = 0x7fffeecf3150}, ipv4={m_address = 167837954}, port=654)
    at ../src/internet-stack/udp-socket-impl.cc:602
#6  0x00002aaf04c67e1f in ns3::MemPtrCallbackImpl<ns3::Ptr<ns3::UdpSocketImpl>,
void (ns3::UdpSocketImpl::*)(ns3::Ptr<ns3::Packet>, ns3::Ipv4Address, unsigned
short), void, ns3::Ptr<ns3::Packet>, ns3::Ipv4Address, unsigned short,
ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty,
ns3::empty>::operator()
    (this=0xaf67c80, a1={m_ptr = 0x7fffeecf31a0}, a2={m_address = 167837954},
a3=654) at debug/ns3/callback.h:229
#7  0x00002aaf04c38ce0 in ns3::Callback<void, ns3::Ptr<ns3::Packet>,
ns3::Ipv4Address, unsigned short, ns3::empty, ns3::empty, ns3::empty,
ns3::empty, ns3::empty, ns3::empty>::operator() (this=0xaf67c38, a1={m_ptr =
0x7fffeecf3200}, a2={m_address = 167837954}, a3=654) at
debug/ns3/callback.h:416
#8  0x00002aaf04c38577 in ns3::Ipv4EndPoint::DoForwardUp (this=0xaf67c20,
p={m_ptr = 0x7fffeecf3250}, saddr={m_address = 167837954}, sport=654)
    at ../src/internet-stack/ipv4-end-point.cc:119
#9  0x00002aaf04c38704 in Notify (this=0xb018a90) at debug/ns3/make-event.h:167


I printed out the destination and origin for this failure for the RREP
header of the packet which shows they are legitimate addresses:

RREP destination 10.1.1.26 RREP origin 10.1.1.31

Attached is a script that reproduces the problem.  I was unable to start
exactly with 40 nodes to reproduce the problem.  It has to start at 10 nodes
and then build up to 40 nodes for the problem to happen.

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.