[Ns-developers] debugging ns-3 bindings problems

Tom Henderson tomh at tomh.org
Wed May 27 22:21:02 PDT 2009


Gustavo,

I'm having the following problem with bindings in ~tomh/ns-3-ip-routing 
directory and am wondering how you would suggest to debug it or deal 
with it.

Consider the class hierarchy:

class A : public Object
{
public:
   static TypeId GetTypeId (void);

   virtual void AMethod (void) = 0;

};
class B : public A
{
public:
   static TypeId GetTypeId (void);

   virtual void BMethod (void) = 0;
};
class BImpl : public B
{
public:
   static TypeId GetTypeId (void);

   void AMethod (void);
   void BMethod (void);
};


this generates, after the binding generation process, the following 
class (among other classes):

class PyNs3B__PythonHelper : public ns3::B
{
public:
   ...
     virtual void BMethod();

     virtual void AMethod();
   ...
}

so, objects of type PyNs3B__PythonHelper can be instantiated even though 
ns3::B is an abstract base class, and everything builds fine.

However, the test case above is analogous to real classes in 
ns-3-ip-routing, where class A is really class Ipv4RoutingProtocol, and 
class B is really class Ipv4StaticRouting : public class 
Ipv4RoutingProtocol (and there is also a corresponding Impl class).

In this case, the bindings code is not generating the equivalent 
PyNs3B__PythonHelper::AMethod(), which in this case is 
PyNs3Ipv4StaticRouting__PythonHelper::RouteOutput().  What follows is a 
compilation error such as:

debug/bindings/python/ns3module.h: In function ‘ns3::Ptr<T> 
ns3::CreateObjectPython(PyObject*, const ns3::AttributeList&) [with T = 
PyNs3Ipv4StaticRouting__PythonHelper]’:
debug/bindings/python/ns3_module_node.cc:29253:   instantiated from here
debug/bindings/python/ns3module.h:16342: error: cannot allocate an 
object of abstract type ‘PyNs3Ipv4StaticRouting__PythonHelper’
debug/bindings/python/ns3module.h:5647: note:   because the following 
virtual functions are pure within ‘PyNs3Ipv4StaticRouting__PythonHelper’:
debug/ns3/ipv4-routing-protocol.h:66: note:     virtual 
ns3::Ptr<ns3::Ipv4Route> ns3::Ipv4RoutingProtocol::RouteOutput(const 
ns3::Ipv4Header&, uint32_t, ns3::Socket::SocketErrno&)
...

Nothing in ns3modulegen.log seems to suggest what may be going wrong, 
and the python bindings seem to properly reflect that these methods are 
virtual:

     cls.add_method('RouteOutput',
                    'ns3::Ptr< ns3::Ipv4Route >',
                    [param('ns3::Ipv4Header const &', 'header'), 
param('uint32_t', 'oif'), param('ns3::Socket::SocketErrno &', 
'sockerr')],
                    is_pure_virtual=True, is_virtual=True)


so I was wondering what you might recommend next for debugging a code 
generation problem like this.

- Tom


More information about the Ns-developers mailing list