NS3 assert failed(buffer.h)

[Urvik Upadhyay]

Hello.First of all I can totally understand that I may not get proper help for this question as this post is about NS3-GPSR repository, but still any guidelines will be helpful. :)

I'm trying to run a code in NS3-GPSR and I'm getting the following error:
Testing 3 packets sent
assert failed. cond="m_current >= m_dataStart && m_current <= m_dataEnd", msg="You have attempted to read beyond the bounds of the available buffer space. This usually indicates that a Header::Deserialize or Trailer::Deserialize method is trying to read data which was not written by a Header::Serialize or Trailer::Serialize method. In short: check the code of your Serialize and Deserialize methods.", file=./ns3/buffer.h, line=823
terminate called without an active exception
Command ['/home/urvik/simulators/ns3-gpsr/build/scratch/newten'] terminated with signal SIGIOT. Run it under a debugger to get more information (./waf --run <program> --command-template="gdb --args %s <args>").

Note that the code works perfectly fine for protocols like AODV,OLSR in both repositories- ns-3.17 and NS3-GPSR simulator!!

[Konstantinos]

The output is more or less clear. You are trying to read something from a packet that is not there.

Have you modified anything in the code? What is the scenario you are using to run?

In addition, try to run the scenario under the debugger as the output suggests.

Finally, which version of GPSR did you downloaded? See this https://codereview.appspot.com/5401042/ which has 4 patch-sets. Perhaps the NS3-GPSR repository was based on the first patch-set.

[Urvik Upadhyay]

The output is more or less clear. You are trying to read something from a packet that is not there.

Have you modified anything in the code? What is the scenario you are using to run?

No I haven't modified anything. I'm attaching the code here. This is the same code I'm using for AODV and OLSR and it works even in this repository. Kindly have a look.

In addition, try to run the scenario under the debugger as the output suggests.

The debugger is giving more or less the same output. The output is:

(gdb) run
Starting program: /home/urvik/simulators/ns3-gpsr/build/scratch/newten SIGIOT
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Testing 3 packets sent
assert failed. cond="m_current >= m_dataStart && m_current <= m_dataEnd", msg="You have attempted to read beyond the bounds of the available buffer space. This usually indicates that a Header::Deserialize or Trailer::Deserialize method is trying to read data which was not written by a Header::Serialize or Trailer::Serialize method. In short: check the code of your Serialize and Deserialize methods.", file=./ns3/buffer.h, line=823
terminate called without an active exception

Program received signal SIGABRT, Aborted.
0x00007ffff56b5425 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) quit
A debugging session is active.

    Inferior 1 [process 3690] will be killed.

 

Finally, which version of GPSR did you downloaded? See this https://codereview.appspot.com/5401042/ which has 4 patch-sets. Perhaps the NS3-GPSR repository was based on the first patch-set.

I downloaded zip file from this link.

[Konstantinos]

Please read http://www.nsnam.org/wiki/HOWTO_understand_and_find_cause_of_terminated_with_signal_errors

See the backtrace within GDB to identify where/why did you get that. From which function. 

On Wednesday, April 2, 2014 7:31:54 PM UTC+1, Urvik Upadhyay wrote:

The output is more or less clear. You are trying to read something from a packet that is not there.

Have you modified anything in the code? What is the scenario you are using to run?

No I haven't modified anything. I'm attaching the code here. This is the same code I'm using for AODV and OLSR and it works even in this repository. Kindly have a look.

In addition, try to run the scenario under the debugger as the output suggests.

The debugger is giving more or less the same output. The output is:

(gdb) run
Starting program: /home/urvik/simulators/ns3-gpsr/build/scratch/newten SIGIOT
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Testing 3 packets sent
assert failed. cond="m_current >= m_dataStart && m_current <= m_dataEnd", msg="You have attempted to read beyond the bounds of the available buffer space. This usually indicates that a Header::Deserialize or Trailer::Deserialize method is trying to read data which was not written by a Header::Serialize or Trailer::Serialize method. In short: check the code of your Serialize and Deserialize methods.", file=./ns3/buffer.h, line=823
terminate called without an active exception

Program received signal SIGABRT, Aborted.
0x00007ffff56b5425 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) quit

At this point instead of quitting, you need to get the backtrace to identify where the crash comes from. 

  

A debugging session is active.

    Inferior 1 [process 3690] will be killed.

 

Finally, which version of GPSR did you downloaded? See this https://codereview.appspot.com/5401042/ which has 4 patch-sets. Perhaps the NS3-GPSR repository was based on the first patch-set.

I downloaded zip file from this link.

I told you, this may be the initial post of GPSR. There are 3 patch-sets that fix certain bugs. It may be the one you have. Try the latest set.

[Urvik Upadhyay]

On Thursday, 3 April 2014 00:36:24 UTC+5:30, Konstantinos wrote:

Please read http://www.nsnam.org/wiki/HOWTO_understand_and_find_cause_of_terminated_with_signal_errors

See the backtrace within GDB to identify where/why did you get that. From which function. 

I'm reading the HOWTO right now. Meanwhile, the backtrace shows following result.

Program received signal SIGABRT, Aborted.
0x00007ffff56b5425 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) backtrace
#0  0x00007ffff56b5425 in __GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff56b8b8b in __GI_abort () at abort.c:91
#2  0x00007ffff622569d in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff6223846 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff6223873 in std::terminate() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff7bafce7 in ns3::Buffer::Iterator::ReadU8 (this=0x7fffffffb130)
    at ./ns3/buffer.h:819
#6  0x00007ffff6844b85 in ns3::Buffer::Iterator::ReadU64 (this=0x7fffffffb130)
    at ../src/network/model/buffer.cc:990
#7  0x00007ffff7baf4e3 in ns3::gpsr::PositionHeader::Deserialize (
    this=0x7fffffffb4b0, start=...) at ../src/gpsr/model/gpsr-packet.cc:249
#8  0x00007ffff6861696 in ns3::Packet::RemoveHeader (this=0x6a3080, header=...)
    at ../src/network/model/packet.cc:268
#9  0x00007ffff7bb29e3 in ns3::gpsr::RoutingProtocol::RouteInput (
    this=0x668750, p=..., header=..., idev=..., ucb=..., mcb=..., lcb=...,
    ecb=...) at ../src/gpsr/model/gpsr.cc:195
#10 0x00007ffff74b50ba in ns3::Ipv4L3Protocol::Receive (this=0x668330,
    device=..., p=..., protocol=2048, from=..., to=..., packetType=0)
    at ../src/internet/model/ipv4-l3-protocol.cc:503
#11 0x00007ffff74cf227 in ns3::MemPtrCallbackImpl<ns3::Ipv4L3Protocol*, void (ns---Type <return> to continue, or q <return> to quit---


 

I told you, this may be the initial post of GPSR. There are 3 patch-sets that fix certain bugs. It may be the one you have. Try the latest set.

I downloaded patch 4 and copied it to the src directory. Still same results. :/

[Konstantinos]

On Wednesday, April 2, 2014 8:41:33 PM UTC+1, Urvik Upadhyay wrote:

On Thursday, 3 April 2014 00:36:24 UTC+5:30, Konstantinos wrote:

Please read http://www.nsnam.org/wiki/HOWTO_understand_and_find_cause_of_terminated_with_signal_errors

See the backtrace within GDB to identify where/why did you get that. From which function. 

I'm reading the HOWTO right now. Meanwhile, the backtrace shows following result.
Program received signal SIGABRT, Aborted.
0x00007ffff56b5425 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) backtrace
#0  0x00007ffff56b5425 in __GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff56b8b8b in __GI_abort () at abort.c:91
#2  0x00007ffff622569d in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff6223846 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff6223873 in std::terminate() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff7bafce7 in ns3::Buffer::Iterator::ReadU8 (this=0x7fffffffb130)
    at ./ns3/buffer.h:819
#6  0x00007ffff6844b85 in ns3::Buffer::Iterator::ReadU64 (this=0x7fffffffb130)
    at ../src/network/model/buffer.cc:990
#7  0x00007ffff7baf4e3 in ns3::gpsr::PositionHeader::Deserialize (
    this=0x7fffffffb4b0, start=...) at ../src/gpsr/model/gpsr-packet.cc:249

If you see this point, it is the PositionHeader that it is trying to read and maybe the particular packet does not have a position-header. 

It might be a packet that was not gone through the GPSR::RouteOutput method to add it. I do not know. You have to identify that and if you find the reason it causes it, you are most welcome to reply back with a patch.

[NHBYK]

Konstantinos <dinos.katsaros@...> writes:

>
>
>
> On Wednesday, April 2, 2014 8:41:33 PM UTC+1, Urvik Upadhyay wrote:
> On Thursday, 3 April 2014 00:36:24 UTC+5:30, Konstantinos wrote:Please
read http://www.nsnam.org/wiki/HOWTO_understand_and_find_cause_of_terminated
_with_signal_errors
> See the backtrace within GDB to identify where/why did you get that. From
which function. 
>
>
> I'm reading the HOWTO right now. Meanwhile, the backtrace shows following

result.Program received signal SIGABRT, Aborted.0x00007ffff56b5425 in

__GI_raise (sig=<optimized out>)    at
../nptl/sysdeps/unix/sysv/linux/raise.c:6464   
../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.(gdb)

backtrace#0  0x00007ffff56b5425 in __GI_raise (sig=<optimized out>)    at
../nptl/sysdeps/unix/sysv/linux/raise.c:64#1  0x00007ffff56b8b8b in
__GI_abort () at abort.c:91#2  0x00007ffff622569d in
__gnu_cxx::__verbose_terminate_handler() ()   from /usr/lib/x86_64-linux-
gnu/libstdc++.so.6#3  0x00007ffff6223846 in ?? () from /usr/lib/x86_64-

linux-gnu/libstdc++.so.6#4  0x00007ffff6223873 in std::terminate() ()   from

/usr/lib/x86_64-linux-gnu/libstdc++.so.6#5  0x00007ffff7bafce7 in

ns3::Buffer::Iterator::ReadU8 (this=0x7fffffffb130)    at

./ns3/buffer.h:819#6  0x00007ffff6844b85 in ns3::Buffer::Iterator::ReadU64

(this=0x7fffffffb130)    at ../src/network/model/buffer.cc:990#7 
0x00007ffff7baf4e3 in ns3::gpsr::PositionHeader::Deserialize (   
this=0x7fffffffb4b0, start=...) at ../src/gpsr/model/gpsr-packet.cc:249
>
>
>
> If you see this point, it is the PositionHeader that it is trying to read
and maybe the particular packet does not have a position-header. 
> It might be a packet that was not gone through the GPSR::RouteOutput
method to add it. I do not know. You have to identify that and if you find
the reason it causes it, you are most welcome to reply back with a patch.
>  
>
> #8  0x00007ffff6861696 in ns3::Packet::RemoveHeader (this=0x6a3080,

header=...)    at ../src/network/model/packet.cc:268#9  0x00007ffff7bb29e3

in ns3::gpsr::RoutingProtocol::RouteInput (    this=0x668750, p=...,
header=..., idev=..., ucb=..., mcb=..., lcb=...,     ecb=...) at

../src/gpsr/model/gpsr.cc:195#10 0x00007ffff74b50ba in

ns3::Ipv4L3Protocol::Receive (this=0x668330,     device=..., p=...,
protocol=2048, from=..., to=..., packetType=0)    at

../src/internet/model/ipv4-l3-protocol.cc:503#11 0x00007ffff74cf227 in

ns3::MemPtrCallbackImpl<ns3::Ipv4L3Protocol*, void (ns---Type <return> to
continue, or q <return> to quit--- 
>
> I told you, this may be the initial post of GPSR. There are 3 patch-sets
that fix certain bugs. It may be the one you have. Try the latest set.
>
>
> I downloaded patch 4 and copied it to the src directory. Still same
results. :/
>
>
>
>
>
>

I had the same bug that I fixed
send you script nd I will try to help

[Konstantinos]

It would be better if you share your code (the bug fix) with us, so that everyone can use it. 

Also that would not put extra workload to you, everytime someone wants to run GPSR! 

[Urvik Upadhyay]

On Tuesday, 8 April 2014 03:40:41 UTC-7, Nour El Houda Ben Youssef wrote:

I had the same bug that I fixed
send you script nd I will try to help

Woho!! great stuff  !! I badly need help. Sorry for replying late but I've my submissions going on currently and I've been busy these days. Well here is my code. This gives correct output for aodv protocol, but for gpsr it is giving the error. Kindly look at the code and suggest me what is wrong in it.

And as Konstantinos said, you should add a generalized patch so that even others can help themselves. :)

[Urvik Upadhyay]

Dear Konstantinos, I believe you've some idea of GPSR protocol so it would be great if you can help me with this. I was going through gpcr-packet.cc file. Actually I was comparing it with aodv-packet.cc file. What I found is, gpcr needs position of sender and receiver(x and y coordinates).
In all the given examples, the position of sender and receiver is also passed when using an application say onoff.
Now I'm using sumo to generate mobility. How can I pass the position for my scenario? If you've any code or link which can help me, please do share. :)

[Henry]

Hi Urvik,

I am facing the same problem. Do you fix that? Can you share the method? Thanks!

Regards,

H