[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