[Ns-bugs] [Bug 1022] New: Possibly inappropriate ASSERT in tcp-socket-impl.cc

code@nsnam.ece.gatech.edu code at nsnam.ece.gatech.edu
Wed Nov 3 13:38:43 PDT 2010


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

           Summary: Possibly inappropriate ASSERT in tcp-socket-impl.cc
           Product: ns-3
           Version: ns-3.9
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: internet-stack
        AssignedTo: ns-bugs at isi.edu
        ReportedBy: wdr at bell-labs.com
   Estimated Hours: 0.0


In a long-running sim, the following assert failed -- lines 1516-1519 in
tcp-socket-impl.cc, version 3.9 released:

      //buffer this, it'll be read by call to Recv
      UnAckData_t::iterator i = 
          m_bufferedData.find (tcpHeader.GetSequenceNumber () );
      NS_ASSERT(i == m_bufferedData.end ()); //no way it should have been found

This is in TcpSocketImpl::NewRx(), when it handles a duplicate packet.

I gather m_bufferedData holds data that the tcp stack has received from the
peer, but which the application hasn't read yet. So this assert fails when the
stack receives a duplicate packet before the application reads the original
packet.

Granted that's unlikely, but is that really an error? Doesn't that just mean
that the application is slow? Or (as I think happened in our case) the network
was slow and the original packet and the duplicate arrived back-to-back?

So I think this assert isn't appropriate. If that condition is true, the stack
should either discard the newly-arrived duplicate, or replace the original with
the duplicate. I think that if we just remove the assert (and the iterator
declaration) the subsequent code will do the latter, and the Ptr<> mechanism
will release the original packet without a memory leak.

When we commented out that assert out and re-ran the sim, it completed without
a problem.

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


More information about the Ns-bugs mailing list