Bug 38

Summary: ns3::Buffer::Iterator::GetIndex assertion triggered
Product: ns-3 Reporter: Gustavo J. A. M. Carneiro <gjcarneiro>
Component: coreAssignee: ns-bugs <ns-bugs>
Status: RESOLVED FIXED    
Severity: blocker    
Priority: P1    
Version: pre-release   
Hardware: PC   
OS: Linux   
Attachments: patch, run "waf check" to reproduce the bug

Description Gustavo J. A. M. Carneiro 2007-06-18 08:51:48 UTC 
And assertion is being triggered by combining two packets with packet.AddAtEnd (pkt1):

assert failed. file=../src/common/buffer.h, line=526, cond="(m_current + n <= m_dataEnd) && ((m_current + n <= m_zeroStart) || (m_current >= m_zeroEnd))"

This is _very hard_ to reproduce.  I tried to create a MTP (minimal test program), but failed.  In fact, I even had to remove a unit tests from ns-3-dev to be able to reproduce my bug, which suggests that the state of buffer "recycling" machinery is determinant to reproduce the bug.

Unfortunately I was unable to fix the bug, merely worked around it, so i'll just post the patch here in hope that someone more familiar with the inner workings of Buffer will be able to figure it out.
Comment 1 Gustavo J. A. M. Carneiro 2007-06-18 08:52:23 UTC 
Created attachment 24 [details]
patch, run "waf check" to reproduce the bug
Comment 2 Mathieu Lacage 2007-06-18 09:51:49 UTC 
There might be a fix for that bug in the packet-history branch. I have not had time to backport one or two fixes to the trunk.
Comment 3 Gustavo J. A. M. Carneiro 2007-06-18 10:05:38 UTC 
I've hit the bug again with completely different code :-(
This time it is not combining two packets at all. Re-titling.

assert failed. file=../src/common/buffer.h, line=526, cond="(m_current + n <= m_dataEnd) && ((m_current + n <= m_zeroStart) || (m_current >= m_zeroEnd))"

(gdb) bt
#0  0xb7f37176 in ns3::AssertBreakpoint () at ../src/core/assert.cc:51
#1  0xb7e8a49b in ns3::Buffer::Iterator::GetIndex (this=0xbfd774ec, n=2) at ../src/common/buffer.h:522
#2  0xb7e8a5e1 in ns3::Buffer::Iterator::WriteU16 (this=0xbfd774ec, data=0) at ../src/common/buffer.h:569
#3  0xb7d7187d in ns3::OlsrHelloMessageHeader::SerializeTo (this=0xbfd77618, start=
      {m_zeroStart = 0, m_zeroEnd = 0, m_dataEnd = 0, m_current = 0, m_data = 0x804bd91 ""})
    at ../src/routing/olsr/olsr-header.cc:194
#4  0xb7e8b053 in ns3::Chunk::Serialize (this=0xbfd77618, start=
      {m_zeroStart = 0, m_zeroEnd = 0, m_dataEnd = 0, m_current = 0, m_data = 0x804bd91 ""}) at ../src/common/chunk.cc:46
#5  0xb7d76b5b in ns3::Packet::AddHeader<ns3::OlsrHelloMessageHeader> (this=0xbfd77630, header=@0xbfd77618)
    at ultradebug/ns3/packet.h:284
#6  0xb7d7387d in ns3::OlsrHeaderTest::RunTests (this=0xb7d7a948) at ../src/routing/olsr/olsr-header.cc:421
#7  0xb7f40496 in ns3::TestManager::RealRunTests (this=0xb7f6ed80) at ../src/core/test.cc:76
#8  0xb7f4094d in ns3::TestManager::RunTests () at ../src/core/test.cc:67
#9  0x0804861f in main () at ../utils/run-tests.cc:28
Comment 4 Gustavo J. A. M. Carneiro 2007-06-18 10:27:53 UTC 
"hg transplant -s ../ns-3-history/ 723" fixed my original bug, which can be reproduced by the attached patch.

Unfortunately it is not fixing the second code path I experienced that caused the very same assertion.
Comment 5 Gustavo J. A. M. Carneiro 2007-06-18 10:38:03 UTC 
519     uint32_t
520     Buffer::Iterator::GetIndex (uint32_t n)
521     {
522       NS_ASSERT ( 
523           (m_current + n <= m_dataEnd) &&
524           ((m_current + n <= m_zeroStart) ||
525            (m_current >= m_zeroEnd) ||
526            m_zeroStart == m_zeroEnd)
(gdb) p m_current
$1 = 0
(gdb) p n
$2 = 2
(gdb) p m_dataEnd
$3 = 0

I wonder if this could be my bug this time, due to not allocating enough space in the buffer... I have to check...
Comment 6 Gustavo J. A. M. Carneiro 2007-06-18 10:44:07 UTC 
(In reply to comment #5)
> I wonder if this could be my bug this time, due to not allocating enough space
> in the buffer... I have to check...

Right, it was my bug this time :P

I've transplanted your fix to ns-3-dev and pushed it.  Thanks!