[ndnSIM] SIGSEGV when simply assigning one smart pointer to another?

[John Baugh]

Junxiao,

Thank you for the information.  I think the static variable will work.

However, as I had originally described, the program results in a
segmentation fault upon assignment operation with an instance field / data
member.

The only workaround I can really think of, if each PStat object needs its
own copy is to use a static counter and a static array of Popularity
Manager objects.

This still seems silly that it crashes from a simple assignment statement.
I'm also still curious WHY it's doing this exactly and if there's a better
solution.

I had posted a valgrind output but not sure if everyone got that.  I might
have to post it through a link on Google Drive.

Thanks everyone!

John

On Apr 16, 2017 11:56 PM, "Junxiao Shi" <shijunxiao at email.arizona.edu>
wrote:

> Hi John
>
> ndnSIM creates multiple NFD instances in the same address space.
> As a result, any global variable (including static members) you use will
> be shared across all network nodes. If this isn't the intention, the
> implementation is wrong.
>
> Also, as stated in NFD developer guide, the Strategy instance is
> stateless, while all states needed by strategy should be stored in tables.
> If you find more instances of your strategy than the number of nodes, this
> is the reason.
> AsfStrategy is a good example on how to implement a complex strategy with
> multiple components, while still keeping all states in tables.
>
> Yours, Junxiao
>
> On Sat, Apr 15, 2017 at 22:49 John Baugh <jpbaugh at umich.edu> wrote:
>
>> Greetings all,
>>
>> I *think* I may have solved the problem (I will need more testing.)
>>
>> I noticed that my PStrat ctor is called multiple times, so obviously any
>> of the instance variables used by PStrat objects will be at different
>> memory locations.  I think Junxiao's suggestion that the program was trying
>> to destroy the object multiple times might have been accurate.
>>
>> I made the shared_ptr to the PopularityManager object *static *so that
>> all instances will share the same object.  The program does not appear to
>> crash now.
>>
>> I will do further testing, but I think this may have solved the issue.
>> It is still quite bizarre.
>>
>> Thanks,
>>
>> John
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20170417/c9dbb3ce/attachment-0001.html>