[ndnSIM] Simulation terminated with signal SIGSEGV - possible bug

[Junxiao Shi]

Hi John


>    1. Deep in the belly of ns-3 (
>    https://www.nsnam.org/doxygen/simple-ref-count_8h_source.html#l00105)
>    - it appears there is an m_count variable, but it's an unsigned 32 bit
>    integer... not 64 bit.  So I'm wondering if the number of references it's
>    tracking exceeds 4,294,967,295.
>
> As I remember, OP is using a 8GB machine. A pointer on amd64 architecture
is 8 bytes. If 8GB is filled to the brim with pointers to the same
ns3::SimpleRefCount, there are 2^30 pointers. m_count would be 2^30, still
less than 2^32-1. Thus, m_count overflow is impossible.



>    1.
>
>    Alternatively, the problem most clearly (unclearly?) says it's "
>
>
>
>    1.
>
>    Address 0x8 is not stack'd, malloc'd or (recently) free'd
>    and
>
>
> ==1647== Process terminating with default action of signal 11
> (SIGSEGV) ==1647== Access not within mapped region at address 0x8
>
>
> So I'm wondering...  where is this 0x8 address having a value assigned or
> being accessed?  0x8 doesn't seem to be a likely memory address to be
> allocated...  so a pointer is being set to the value "8" somewhere....  I
> don't see you doing that anywhere.  So I'm wondering if there's a buffer
> overflow somewhere.
>
This is easy to explain. Assume you have “struct A { uint64_t x; uint64_t
y; }”, and you have a nil pointer “A* a = nullptr;”. Trying to access
“a->y” causes Valgrind to complain about 0x8 address.
OP’s problem is most likely a memory allocation error. When malloc or C++’s
new operator fails, it returns nullptr, and most programmers do not bother
checking for them.
Rent a bigger machine! The biggest you can get today is 3.75TB RAM,
although 32GB RAM is likely sufficient for this simulation.

Yours, Junxiao

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20180519/a9c79f89/attachment.html>