Bugzilla – Bug 38
ns3::Buffer::Iterator::GetIndex assertion triggered
Last modified: 2007-06-18 10:44:07 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.
Created attachment 24 [details] patch, run "waf check" to reproduce the bug
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.
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
"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.
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...
(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!