[Ns-developers] debugging ns-3 bindings problems

[Mathieu Lacage]

hi tom,

[release manager hat on]

If this is the only issue which is holding your merge of ns-3-ip-routing
in ns-3-dev, I would like to suggest that you merge now rather than wait
that it's fixed in the hope that this will help us get more testing by
other developers of the ip changes. I feel that we can live with the
python stuff being broken for a while. i.e., anyone can run "./waf
configure --disable-python"


Mathieu


On Wed, 2009-05-27 at 22:21 -0700, Tom Henderson wrote:
> 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