[Ns-developers] debugging ns-3 bindings problems

[Gustavo Carneiro]

2009/5/28 Tom Henderson <tomh at tomh.org>

> 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.


True, the method is declared virtual, but is being ignored by pybindgen:

   ../bindings/python/ns3_module_node.py:2852:
TypeLookupError(['ns3::Socket::SocketErrno &'],)

Why this "ns3::Socket::SocketErrno &" type is being rejected by pybindgen I
do not know.  Sounds like a bug.  I am looking into it.  Sorry about that...

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert