NS_ASSERT in packet-metadata.cc, or: how to buffer multiple incoming packets

Marc Reichelt

unread,

Mar 10, 2011, 10:34:12 AM3/10/11

to ns-3-users

Hi!

At the moment I am writing an ns-3 application. It uses two sockets: a
UDP socket for broadcasts and a TCP socket for reliable communication.
For the TCP communication I defined some headers, e.g.:
- A header PRE that precedes every other header and is a simple
(type / length) pair (uint16_t and uint32_t). The length represents
how many bytes will follow.
- Two headers T1 and T2 (type 1 and type 2). T1 is containing all
data, but T2 is some metadata and is followed by a various payload.

As an example, if I want to send two messages of type 1 and one
message of type 2 (including a payload), I send the following data via
the TCP socket:
PRE T1
PRE T1
PRE T2 PAYLOAD

In order to parse complete messages I use an empty packet on the
server side: Ptr<Packet> m_buffer.
All incoming packets are added to the end of the buffer:
while (packet = socket->Recv ())
m_buffer->AddAtEnd (packet);

When parsing the buffer I ensure that there are enough bytes in the
buffer (which I know by removing the PRE header before), then I create
a fragment or copy of the packet:
Ptr<Packet> p = m_buffer->CreateFragment (0, bytes);
m_buffer->RemoveAtStart (bytes);

But when removing the third message (T2 + PAYLOAD) from the buffer I
get the following assertion error:
assert failed. cond="buffer <= &m_data->m_data[m_data->m_size]",
file=../src/common/packet-metadata.cc, line=516

Why do I get this error? I do not try to remove more bytes than the
buffer contains. In fact, I try to remove exactly 2088 bytes from the
buffer, which in this case also has a size of exactly 2088 bytes. Am I
using ns-3 packets correctly - or is the usage of a packet as a buffer
unintended? I tried to use a Buffer instance instead, but then I get
problems putting packets into the buffer or reading packets / headers
from it...

Thanks in advance & regards

Marc Reichelt || http://www.marcreichelt.de/

Mathieu Lacage

unread,

Mar 11, 2011, 4:05:29 AM3/11/11

to ns-3-...@googlegroups.com, Marc Reichelt

On Thu, Mar 10, 2011 at 16:34, Marc Reichelt <mcrei...@googlemail.com> wrote:

> But when removing the third message (T2 + PAYLOAD) from the buffer I
> get the following assertion error:
> assert failed. cond="buffer <= &m_data->m_data[m_data->m_size]",
> file=../src/common/packet-metadata.cc, line=516

backtrace and code for header T2 ?

Mathieu
--
Mathieu Lacage <mathieu...@gmail.com>

Mathieu Lacage

unread,

Mar 15, 2011, 4:28:27 AM3/15/11

to ns-3-...@googlegroups.com, Marc Reichelt

fixed. see bug 1072: http://www.nsnam.org/bugzilla/show_bug.cgi?id=1072

On Thu, Mar 10, 2011 at 16:34, Marc Reichelt <mcrei...@googlemail.com> wrote:

> --
> You received this message because you are subscribed to the Google Groups "ns-3-users" group.
> To post to this group, send email to ns-3-...@googlegroups.com.
> To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.
>
>

--
Mathieu Lacage <mathieu...@gmail.com>

Cristi

unread,

Aug 15, 2012, 12:11:49 PM8/15/12

to ns-3-...@googlegroups.com, Marc Reichelt, mathieu...@gmail.com

Hi all,

this bug seams not to have disappeared completely.
I'm using ns3.10 with the revised code which was supposed to fix this bug.

In my simulations I'm using the packet aggregation feature which makes the simulation crash a lot more than the case when no packet aggregation is used.

I've run my code under gdb and got the following:

assert failed. cond="IsStateOk ()", file=../src/common/packet-metadata.cc, line=866
terminate called without an active exception

Program received signal SIGABRT, Aborted.
0x00007ffff4adb445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x00007ffff4adb445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff4adebab in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff542969d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff5427846 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff5427873 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff6d0927f in ns3::PacketMetadata::AddAtEnd (this=0xb8a910, o=...) at ../src/common/packet-metadata.cc:866
#6 0x00007ffff6d2a4a6 in ns3::Packet::AddAtEnd (this=0xb8a8d0, packet=...) at ../src/common/packet.cc:329
#7 0x00007ffff72b731a in ns3::MsduStandardAggregator::Aggregate (this=0xb77370, packet=..., aggregatedPacket=..., src=...,
    dest=...) at ../src/devices/wifi/msdu-standard-aggregator.cc:78
#8 0x00007ffff72a6917 in ns3::EdcaTxopN::NotifyAccessGranted (this=0x747430) at ../src/devices/wifi/edca-txop-n.cc:562
#9 0x00007ffff72b121e in ns3::EdcaTxopN::Dcf::DoNotifyAccessGranted (this=0x7475d0) at ../src/devices/wifi/edca-txop-n.cc:84
#10 0x00007ffff7231483 in ns3::DcfState::NotifyAccessGranted (this=0x7475d0) at ../src/devices/wifi/dcf-manager.cc:145
#11 0x00007ffff723284c in ns3::DcfManager::DoGrantAccess (this=0x746f70) at ../src/devices/wifi/dcf-manager.cc:434
#12 0x00007ffff723297a in ns3::DcfManager::AccessTimeout (this=0x746f70) at ../src/devices/wifi/dcf-manager.cc:450
#13 0x00007ffff72352ee in ns3::EventMemberImpl0::Notify (this=0xa65670) at debug/ns3/make-event.h:94
#14 0x00007ffff6c88ffc in ns3::EventImpl::Invoke (this=0xa65670) at ../src/simulator/event-impl.cc:37
#15 0x00007ffff6ca6146 in ns3::DefaultSimulatorImpl::ProcessOneEvent (this=0x6d8580)
    at ../src/simulator/default-simulator-impl.cc:128
#16 0x00007ffff6ca62f6 in ns3::DefaultSimulatorImpl::Run (this=0x6d8580) at ../src/simulator/default-simulator-impl.cc:158
#17 0x00007ffff6c89add in ns3::Simulator::Run () at ../src/simulator/simulator.cc:173
#18 0x00000000004298c2 in main (argc=5, argv=0x7fffffffe438) at ../scratch/mesh_voip_fairness_4.cc:1428
(gdb) up
#1 0x00007ffff4adebab in abort () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) up
#2 0x00007ffff542969d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) up
#3 0x00007ffff5427846 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) up
#4 0x00007ffff5427873 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) up
#5 0x00007ffff6d0927f in ns3::PacketMetadata::AddAtEnd (this=0xb8a910, o=...) at ../src/common/packet-metadata.cc:866
866    NS_ASSERT (IsStateOk ());
(gdb) info local
__FUNCTION__ = "AddAtEnd"
tailExtraItem = {fragmentStart = 0, fragmentEnd = 20, packetUid = 264998}
current = 63091
extraItem = {fragmentStart = 0, fragmentEnd = 20, packetUid = 265723}
tailItem = {next = 65535, prev = 65426, typeUid = 1, size = 20, chunkUid = 7824}
tailSize = 14
item = {next = 65535, prev = 63076, typeUid = 1, size = 20, chunkUid = 12033}
(gdb) info args
this = 0xb8a910
o = @0x92f2b0: {
static m_freeList = {<std::vector<ns3::PacketMetadata::Data*, std::allocator<ns3::PacketMetadata::Data*> >> = {<std::_Vector_base<ns3::PacketMetadata::Data*, std::allocator<ns3::PacketMetadata::Data*> >> = {
        _M_impl = {<std::allocator<ns3::PacketMetadata::Data*>> = {<__gnu_cxx::new_allocator<ns3::PacketMetadata::Data*>> = {<No data fields>}, <No data fields>}, _M_start = 0xbb6270, _M_finish = 0xbb6270, _M_end_of_storage =
    0xbb6a70}}, <No data fields>}, <No data fields>}, static m_enable = true, static m_enableChecking = false,
static m_metadataSkipped = false, static m_maxSize = 65544, static m_chunkUid = 62671, m_data = 0x1636a50, m_head = 64289,
m_tail = 63091, m_used = 64298, m_packetUid = 264629}

Please let me and the ns3 community know if you spot something which may lead to another bugfix for this PacketMetadata related issue.

Many thanks,
Cristian

coderc...@gmail.com

unread,

Mar 3, 2013, 9:04:37 AM3/3/13

to ns-3-...@googlegroups.com, Marc Reichelt

Hi,

I am trying to simulate the transmission of packets with variable sizes. When I try to transmit a relatively large packet (say > 8000 bytes) I keep getting NS_ASSERT (IsStateOk ()); from the AddHeader method. I have been trying to understand the code however I cannot seem to point out what the problem is. I do not think its the case that there is a limit on the packet size since packets can be fragmented. But this occurs with large packets. I think it has to do with the buffer iterator 'current' but I am not sure.

I have also looked at https://www.nsnam.org/bugzilla/show_bug.cgi?id=1072 and the suggested changeset...I am working with version of 3-16, which includes the changes I think. Any insight of what might be triggering this and the solution please?

Cristi

unread,

Mar 7, 2013, 10:02:39 AM3/7/13

to ns-3-...@googlegroups.com, Marc Reichelt

Hi all,

I'm running a wifi mesh setup with OLSR routing and 802.11e aggregation feature enabled. After a while of running the setup, the simulation crashes with:

"assert failed. cond="IsStateOk ()", file=../src/common/packet-metadata.cc, line=888"

I've looked into it, and got this gdb trace:

Program received signal SIGABRT, Aborted.

0x00007ffff4ac4425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64

64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.

(gdb) bt

#0 0x00007ffff4ac4425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64

#1 0x00007ffff4ac7b8b in __GI_abort () at abort.c:91

#2 0x00007ffff53bfe2d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

#3 0x00007ffff53bdf26 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

#4 0x00007ffff53bdf53 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

#5 0x00007ffff6cfcf5b in ns3::PacketMetadata::AddAtEnd (this=0x9e4820, o=...) at ../src/common/packet-metadata.cc:888

#6 0x00007ffff6d20d22 in ns3::Packet::AddAtEnd (this=0x9e47e0, packet=...) at ../src/common/packet.cc:329

#7 0x00007ffff72b4936 in ns3::MsduStandardAggregator::Aggregate (this=0x9ef3e0, packet=..., aggregatedPacket=..., src=..., dest=...) at ../src/devices/wifi/msdu-standard-aggregator.cc:78

#8 0x00007ffff72a3f39 in ns3::EdcaTxopN::NotifyAccessGranted (this=0x7427b0) at ../src/devices/wifi/edca-txop-n.cc:590

#9 0x00007ffff72ae83a in ns3::EdcaTxopN::Dcf::DoNotifyAccessGranted (this=0x742950) at ../src/devices/wifi/edca-txop-n.cc:111

#10 0x00007ffff722e783 in ns3::DcfState::NotifyAccessGranted (this=0x742950) at ../src/devices/wifi/dcf-manager.cc:145

#11 0x00007ffff722fb4c in ns3::DcfManager::DoGrantAccess (this=0x7422f0) at ../src/devices/wifi/dcf-manager.cc:434

#12 0x00007ffff722fc7a in ns3::DcfManager::AccessTimeout (this=0x7422f0) at ../src/devices/wifi/dcf-manager.cc:450

#13 0x00007ffff72325ee in ns3::EventMemberImpl0::Notify (this=0x949860) at debug/ns3/make-event.h:94

#14 0x00007ffff6c7b18c in ns3::EventImpl::Invoke (this=0x949860) at ../src/simulator/event-impl.cc:37

#15 0x00007ffff6c982d6 in ns3::DefaultSimulatorImpl::ProcessOneEvent (this=0x6dd4c0) at ../src/simulator/default-simulator-impl.cc:128

#16 0x00007ffff6c98486 in ns3::DefaultSimulatorImpl::Run (this=0x6dd4c0) at ../src/simulator/default-simulator-impl.cc:158

#17 0x00007ffff6c7bc6d in ns3::Simulator::Run () at ../src/simulator/simulator.cc:173

#18 0x000000000042d3dd in main (argc=9, argv=0x7fffffffe3e8) at ../scratch/fom.cc:1680

So when the aggregator is called the simulation crashes, but after many successful aggregations.

In the packet-metadata.h file there is this statement:

"

* This linked list is flattened in a byte buffer stored in

* struct PacketMetadata::Data. Each entry of the linked list is

* identified by an offset which identifies the first byte of the

* entry from the start of the data buffer. The size of this data

* buffer is 2^16-1 bytes maximum which somewhat limits the number

* of entries which can be stored in this linked list but it is

* quite unlikely to hit this limit in practice. "

Question: when do you thing is possible that 2^16-1 can be overflown?

I have logged the value of the m_used and m_size variables of the PacketMetadata class. It seams that at some point everything goes wrong and their values increase so much that they overflow the max limit.

Here are the last lines of log before the crash happened:

68.8601 OK: Line136 - m_used: 65042 m_size: 65042

68.8601 OK: Line136 - m_used: 65131 m_size: 65131

68.86:n:17:napi:3