Bug report: Config::Set may fail to set the attribute by using Names::Add

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug report: Config::Set may fail to set the attribute by using Names::Add

Dizhi Zhou-2
*/*Description*/*
Consider the following example script:
   // create a node
  NodeContainer nodes;
  nodes.Create (1);

   // install a P2P netdevice to the node
  PointToPointHelper pointToPoint;
  NetDeviceContainer devices;
  devices = pointToPoint.Install (nodes);

  // Add internet stack
  InternetStackHelper stack;
  stack.Install (nodes);

  // Define alias strings to represent the node and the netdevice
  Names::Add ("client", nodes.Get (0));
  Names::Add ("client/device", nodes.Get (0)->GetDevice (0));

  // Set DataRate attribute using such alias strings
  Config::Set ("/Names/client/device/$ns3::PointToPointNetDevice/DataRate",
StringValue ("2.5Mbps"));

The Config::Set doesn't work. The DataRate attribute is still equal to its
original default value (i,e, 32768bps).

However, the Config::Set works when we InternetStackHelper::Install() is
called after Names::Add and Config::Set.

*/* Root cause analysis */*
In Config::Set call stack, it calls Names::Find () to get the object
pointer of a string.
Resolver::DoResolve ()
{
  ...
  Ptr<Object> namedObject = *Names::Find<Object>* (root, item);
  ...
}

I print the namedObject name and item in both two cases
// Case 1: use InternetStackHelper::Install() *after* Config::Set and
Names::Add
item == client,  but namedObject == Node // expected results

// Case 2: use InternetStackHelper::Install() *before* Config::Set and
Names::Add
item == client,  but namedObject == Ipv4L3Protocol

In Case 2, Config::Set fails since it's unable find PointToPointNetDevice
from Ipv4L3Protocol.

Why Names::Find returns Ipv4L3Protocol instead of Node?
template <typename T>
/* static */
Ptr<T>
Names::Find (Ptr<Object> context, std::string name)
{
  Ptr<Object> obj = FindInternal (context, name);
  if (obj)
    {
      return *obj->GetObject<T> ();*
    }
...
}

In our example, T== Object, name == "client", obj == Node. . However,
obj->GetObject<T> returns object Ipv4L3Protocol, instead of object Node!!

Why?
template <typename T>
Ptr<T>
Object::GetObject () const
{
  // This is an optimization: if the cast works (which is likely),
  // things will be pretty fast.
  T *result = dynamic_cast<T *> (m_aggregates->buffer[0]);
  if (result != 0)
    {
      return Ptr<T> (result);
    }
  // if the cast does not work, we try to do a full type check.
  Ptr<Object> found = DoGetObject (T::GetTypeId ());
  if (found != 0)
    {
      return Ptr<T> (static_cast<T *> (PeekPointer (found)));
    }
  return 0;
}

GetObject() always do a dynamic_cast on the first object in the aggregate
list. In our case, Since T == Object in Case 2, such dynamic_cast always
successes. Therefore, Names::Find<Object>(root, item) can only return the
first object in the root's aggregation list.

In my example, before using InternetStackHelper::Instal(), the only object
in the Node aggregation list is the Node itself. After calling this
function, however, Ipv4L3Protocol becomes the first object in that list,
which causes the Config::Set failure.


*/*Solution*/*
For all Names::Find functions, use GetObject (TypeId), instead of
GetObject()

Names::Find (Ptr<Object> context, std::string name)
{
  Ptr<Object> obj = FindInternal (context, name);
  if (obj)
    {
      return *obj->GetObject<**obj->GetInstanceTypeId ()> ();*
    }
...
}

GetObject (TypeId) function will find the specified object from the
aggregate object list.

template <typename T>
Ptr<T>
Object::GetObject (TypeId tid) const
{
  Ptr<Object> found = DoGetObject (tid);
  if (found != 0)
    {
      return Ptr<T> (static_cast<T *> (PeekPointer (found)));
    }
  return 0;
}

I only test this solution in such example script. I may do a fully test and
add some test examples in this summer during my spare time.


Regards,
Dizhi
Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Config::Set may fail to set the attribute by using Names::Add

Manoj Rana
Hi,
Better not to send the code, you could introduce the problem first i.e.
what you understand about the problem. It would be more meaningful for the
developers.
Regards,
manoj

On Thu, Jun 15, 2017 at 8:03 PM, Dizhi Zhou <[hidden email]> wrote:

> */*Description*/*
> Consider the following example script:
>    // create a node
>   NodeContainer nodes;
>   nodes.Create (1);
>
>    // install a P2P netdevice to the node
>   PointToPointHelper pointToPoint;
>   NetDeviceContainer devices;
>   devices = pointToPoint.Install (nodes);
>
>   // Add internet stack
>   InternetStackHelper stack;
>   stack.Install (nodes);
>
>   // Define alias strings to represent the node and the netdevice
>   Names::Add ("client", nodes.Get (0));
>   Names::Add ("client/device", nodes.Get (0)->GetDevice (0));
>
>   // Set DataRate attribute using such alias strings
>   Config::Set ("/Names/client/device/$ns3::PointToPointNetDevice/
> DataRate",
> StringValue ("2.5Mbps"));
>
> The Config::Set doesn't work. The DataRate attribute is still equal to its
> original default value (i,e, 32768bps).
>
> However, the Config::Set works when we InternetStackHelper::Install() is
> called after Names::Add and Config::Set.
>
> */* Root cause analysis */*
> In Config::Set call stack, it calls Names::Find () to get the object
> pointer of a string.
> Resolver::DoResolve ()
> {
>   ...
>   Ptr<Object> namedObject = *Names::Find<Object>* (root, item);
>   ...
> }
>
> I print the namedObject name and item in both two cases
> // Case 1: use InternetStackHelper::Install() *after* Config::Set and
> Names::Add
> item == client,  but namedObject == Node // expected results
>
> // Case 2: use InternetStackHelper::Install() *before* Config::Set and
> Names::Add
> item == client,  but namedObject == Ipv4L3Protocol
>
> In Case 2, Config::Set fails since it's unable find PointToPointNetDevice
> from Ipv4L3Protocol.
>
> Why Names::Find returns Ipv4L3Protocol instead of Node?
> template <typename T>
> /* static */
> Ptr<T>
> Names::Find (Ptr<Object> context, std::string name)
> {
>   Ptr<Object> obj = FindInternal (context, name);
>   if (obj)
>     {
>       return *obj->GetObject<T> ();*
>     }
> ...
> }
>
> In our example, T== Object, name == "client", obj == Node. . However,
> obj->GetObject<T> returns object Ipv4L3Protocol, instead of object Node!!
>
> Why?
> template <typename T>
> Ptr<T>
> Object::GetObject () const
> {
>   // This is an optimization: if the cast works (which is likely),
>   // things will be pretty fast.
>   T *result = dynamic_cast<T *> (m_aggregates->buffer[0]);
>   if (result != 0)
>     {
>       return Ptr<T> (result);
>     }
>   // if the cast does not work, we try to do a full type check.
>   Ptr<Object> found = DoGetObject (T::GetTypeId ());
>   if (found != 0)
>     {
>       return Ptr<T> (static_cast<T *> (PeekPointer (found)));
>     }
>   return 0;
> }
>
> GetObject() always do a dynamic_cast on the first object in the aggregate
> list. In our case, Since T == Object in Case 2, such dynamic_cast always
> successes. Therefore, Names::Find<Object>(root, item) can only return the
> first object in the root's aggregation list.
>
> In my example, before using InternetStackHelper::Instal(), the only object
> in the Node aggregation list is the Node itself. After calling this
> function, however, Ipv4L3Protocol becomes the first object in that list,
> which causes the Config::Set failure.
>
>
> */*Solution*/*
> For all Names::Find functions, use GetObject (TypeId), instead of
> GetObject()
>
> Names::Find (Ptr<Object> context, std::string name)
> {
>   Ptr<Object> obj = FindInternal (context, name);
>   if (obj)
>     {
>       return *obj->GetObject<**obj->GetInstanceTypeId ()> ();*
>     }
> ...
> }
>
> GetObject (TypeId) function will find the specified object from the
> aggregate object list.
>
> template <typename T>
> Ptr<T>
> Object::GetObject (TypeId tid) const
> {
>   Ptr<Object> found = DoGetObject (tid);
>   if (found != 0)
>     {
>       return Ptr<T> (static_cast<T *> (PeekPointer (found)));
>     }
>   return 0;
> }
>
> I only test this solution in such example script. I may do a fully test and
> add some test examples in this summer during my spare time.
>
>
> Regards,
> Dizhi
>
Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Config::Set may fail to set the attribute by using Names::Add

Dizhi Zhou-2
Hi Manoj,

In brief, the problem I see is that Config::Set function may fail to set an
attribute if 1) its name-space path uses a string defined by Names::Add and
2) Config::Set is called after any object aggregation (e.g.,
InternetStackHelper::Install() function).

How to reproduce this problem can be found  in the "/*Description*/"
section of my first Email (
http://mailman.isi.edu/pipermail/ns-developers/2017-June/013967.html).

My first Email explained the root cause of this bug and proposed a solution
as well.

Please let me know if you have any other questions.

Regards,
Dizhi

Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Config::Set may fail to set the attribute by using Names::Add

Barnes, Peter D.
Hello Dizhi,

I added this to our bug tracker:
https://www.nsnam.org/bugzilla/show_bug.cgi?id=2765

Thanks for the detailed report.
Peter


On Jun 15, 2017, at 10:56 AM, Dizhi Zhou <[hidden email]<mailto:[hidden email]>> wrote:

Hi Manoj,

In brief, the problem I see is that Config::Set function may fail to set an
attribute if 1) its name-space path uses a string defined by Names::Add and
2) Config::Set is called after any object aggregation (e.g.,
InternetStackHelper::Install() function).

How to reproduce this problem can be found  in the "/*Description*/"
section of my first Email (
http://mailman.isi.edu/pipermail/ns-developers/2017-June/013967.html).

My first Email explained the root cause of this bug and proposed a solution
as well.

Please let me know if you have any other questions.

Regards,
Dizhi


_____________________________________________________________
Dr. Peter D. Barnes, Jr. NACS Division
Lawrence Livermore National Laboratory Physical and Life Sciences
7000 East Avenue, L-50 email:  [hidden email]<mailto:[hidden email]>
P. O. Box 808 Voice:  (925) 422-3384
Livermore, California 94550 Fax:    (925) 423-3371





Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Config::Set may fail to set the attribute by using Names::Add

Dizhi Zhou-2
Hi Peter,

Thanks. Do you know who should be the right owner for this bug? The fix is
very simple (explained in my first Email). However, we need to add more
test suites to verify the fix.

Regards,
Dizhi

On Mon, Jul 10, 2017 at 6:27 PM, Barnes, Peter D. <[hidden email]> wrote:

> Hello Dizhi,
>
> I added this to our bug tracker:
> https://www.nsnam.org/bugzilla/show_bug.cgi?id=2765
>
> Thanks for the detailed report.
> Peter
>
>
> On Jun 15, 2017, at 10:56 AM, Dizhi Zhou <[hidden email]> wrote:
>
> Hi Manoj,
>
> In brief, the problem I see is that Config::Set function may fail to set an
> attribute if 1) its name-space path uses a string defined by Names::Add and
> 2) Config::Set is called after any object aggregation (e.g.,
> InternetStackHelper::Install() function).
>
> How to reproduce this problem can be found  in the "/*Description*/"
> section of my first Email (
> http://mailman.isi.edu/pipermail/ns-developers/2017-June/013967.html).
>
> My first Email explained the root cause of this bug and proposed a solution
> as well.
>
> Please let me know if you have any other questions.
>
> Regards,
> Dizhi
> ​
>
>
> _____________________________________________________________
> Dr. Peter D. Barnes, Jr. NACS Division
> Lawrence Livermore National Laboratory Physical and Life Sciences
> 7000 East Avenue, L-50 email:  [hidden email]
> P. O. Box 808 Voice:  (925) 422-3384
> Livermore, California 94550 Fax:    (925) 423-3371
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Config::Set may fail to set the attribute by using Names::Add

Peter Barnes-4
Since the fix will be in the core module I should be one of the owners.

Anyone can get a Bugzilla account; I didn't find one for you. This will let you create new bug reports (like I did for you), post patches, comment on bugs (like you did below), and contribute to consensus on when a patch is complete and ready to merge.

Dive in!

Thanks,
Peter

------------------
[hidden email]

> On Jul 10, 2017, at 5:33 PM, Dizhi Zhou <[hidden email]> wrote:
>
> Hi Peter,
>
> Thanks. Do you know who should be the right owner for this bug? The fix is
> very simple (explained in my first Email). However, we need to add more
> test suites to verify the fix.
>
> Regards,
> Dizhi
>
>> On Mon, Jul 10, 2017 at 6:27 PM, Barnes, Peter D. <[hidden email]> wrote:
>>
>> Hello Dizhi,
>>
>> I added this to our bug tracker:
>> https://www.nsnam.org/bugzilla/show_bug.cgi?id=2765
>>
>> Thanks for the detailed report.
>> Peter
>>
>>
>> On Jun 15, 2017, at 10:56 AM, Dizhi Zhou <[hidden email]> wrote:
>>
>> Hi Manoj,
>>
>> In brief, the problem I see is that Config::Set function may fail to set an
>> attribute if 1) its name-space path uses a string defined by Names::Add and
>> 2) Config::Set is called after any object aggregation (e.g.,
>> InternetStackHelper::Install() function).
>>
>> How to reproduce this problem can be found  in the "/*Description*/"
>> section of my first Email (
>> http://mailman.isi.edu/pipermail/ns-developers/2017-June/013967.html).
>>
>> My first Email explained the root cause of this bug and proposed a solution
>> as well.
>>
>> Please let me know if you have any other questions.
>>
>> Regards,
>> Dizhi
>> ​
>>
>>
>> _____________________________________________________________
>> Dr. Peter D. Barnes, Jr. NACS Division
>> Lawrence Livermore National Laboratory Physical and Life Sciences
>> 7000 East Avenue, L-50 email:  [hidden email]
>> P. O. Box 808 Voice:  (925) 422-3384
>> Livermore, California 94550 Fax:    (925) 423-3371
>>
>>
>>
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Config::Set may fail to set the attribute by using Names::Add

Tommaso Pecorella
In reply to this post by Dizhi Zhou-2
Hi Dizhi,

I see your e-mail in Bugzilla as “[hidden email]”, is this right ?

About the bug and its fix, it seems reasonable to me, but… can you provide a patch (and perhaps a test) ?
Thanks,

T.



> On 11 Jul 2017, at 02:33, Dizhi Zhou <[hidden email]> wrote:
>
> Hi Peter,
>
> Thanks. Do you know who should be the right owner for this bug? The fix is
> very simple (explained in my first Email). However, we need to add more
> test suites to verify the fix.
>
> Regards,
> Dizhi
>
> On Mon, Jul 10, 2017 at 6:27 PM, Barnes, Peter D. <[hidden email]> wrote:
>
>> Hello Dizhi,
>>
>> I added this to our bug tracker:
>> https://www.nsnam.org/bugzilla/show_bug.cgi?id=2765
>>
>> Thanks for the detailed report.
>> Peter
>>
>>
>> On Jun 15, 2017, at 10:56 AM, Dizhi Zhou <[hidden email]> wrote:
>>
>> Hi Manoj,
>>
>> In brief, the problem I see is that Config::Set function may fail to set an
>> attribute if 1) its name-space path uses a string defined by Names::Add and
>> 2) Config::Set is called after any object aggregation (e.g.,
>> InternetStackHelper::Install() function).
>>
>> How to reproduce this problem can be found  in the "/*Description*/"
>> section of my first Email (
>> http://mailman.isi.edu/pipermail/ns-developers/2017-June/013967.html).
>>
>> My first Email explained the root cause of this bug and proposed a solution
>> as well.
>>
>> Please let me know if you have any other questions.
>>
>> Regards,
>> Dizhi
>> ​
>>
>>
>> _____________________________________________________________
>> Dr. Peter D. Barnes, Jr. NACS Division
>> Lawrence Livermore National Laboratory Physical and Life Sciences
>> 7000 East Avenue, L-50 email:  [hidden email]
>> P. O. Box 808 Voice:  (925) 422-3384
>> Livermore, California 94550 Fax:    (925) 423-3371
>>
>>
>>
>>
>>
>>

--------------------------------------------------------------

``... anyone can do any amount of work, provided it isn't the
  work he is supposed to be doing at that moment.''
-- Robert Benchley, in Chips off the Old Benchley, 1949

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Ingegneria dell'Informazione
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: [hidden email]
       [hidden email]

phone : +39-055-2758540
mobile: +39-320-4379803
fax   : +39-055-2758570








Reply | Threaded
Open this post in threaded view
|

Re: Bug report: Config::Set may fail to set the attribute by using Names::Add

Dizhi Zhou-2
That's my previous Email. I will use my Gmail to register a new account. I
can submit a patch sometime in this summer:)

Regards,
Dizhi

On Wed, Jul 12, 2017 at 8:44 AM, Tommaso Pecorella <[hidden email]>
wrote:

> Hi Dizhi,
>
> I see your e-mail in Bugzilla as “[hidden email]”, is this right ?
>
> About the bug and its fix, it seems reasonable to me, but… can you provide
> a patch (and perhaps a test) ?
> Thanks,
>
> T.
>
>
>
> On 11 Jul 2017, at 02:33, Dizhi Zhou <[hidden email]> wrote:
>
> Hi Peter,
>
> Thanks. Do you know who should be the right owner for this bug? The fix is
> very simple (explained in my first Email). However, we need to add more
> test suites to verify the fix.
>
> Regards,
> Dizhi
>
> On Mon, Jul 10, 2017 at 6:27 PM, Barnes, Peter D. <[hidden email]>
> wrote:
>
> Hello Dizhi,
>
> I added this to our bug tracker:
> https://www.nsnam.org/bugzilla/show_bug.cgi?id=2765
>
> Thanks for the detailed report.
> Peter
>
>
> On Jun 15, 2017, at 10:56 AM, Dizhi Zhou <[hidden email]> wrote:
>
> Hi Manoj,
>
> In brief, the problem I see is that Config::Set function may fail to set an
> attribute if 1) its name-space path uses a string defined by Names::Add and
> 2) Config::Set is called after any object aggregation (e.g.,
> InternetStackHelper::Install() function).
>
> How to reproduce this problem can be found  in the "/*Description*/"
> section of my first Email (
> http://mailman.isi.edu/pipermail/ns-developers/2017-June/013967.html).
>
> My first Email explained the root cause of this bug and proposed a solution
> as well.
>
> Please let me know if you have any other questions.
>
> Regards,
> Dizhi
> ​
>
>
> _____________________________________________________________
> Dr. Peter D. Barnes, Jr. NACS Division
> Lawrence Livermore National Laboratory Physical and Life Sciences
> 7000 East Avenue, L-50 email:  [hidden email]
> P. O. Box 808 Voice:  (925) 422-3384
> Livermore, California 94550 Fax:    (925) 423-3371
>
>
>
>
>
>
>
> --------------------------------------------------------------
>
> ``... anyone can do any amount of work, provided it isn't the
>   work he is supposed to be doing at that moment.''
> -- Robert Benchley, in Chips off the Old Benchley, 1949
>
> --------------------------------------------------------------
>
> Tommaso Pecorella - Ph.D.
>
> Assistant professor
> Dpt. Ingegneria dell'Informazione
> Università di Firenze
>
> CNIT - Università di Firenze Unit
>
> via di S. Marta 3
> 50139, Firenze
> ITALY
>
> email: [hidden email]
>        [hidden email]
>
> phone : +39-055-2758540 <+39%20055%20275%208540>
> mobile: +39-320-4379803 <+39%20320%20437%209803>
> fax   : +39-055-2758570 <+39%20055%20275%208570>
>
>
>
>
>
>
>
>
>