C++ destructors not being called?

[rdeits]

I just started experimenting with swig-matlab as a possible way to replace our huge amount of hand-written mexFunction code, and it looks very promising. However, I'm having trouble understanding how wrapped C++ classes are handled: it looks like the class destructor is never called, and the class may never be deallocated.

My test case is something like this:

#include <iostream>

class Foo {
public:
  Foo() {
    std::cout << "allocating a new Foo" << std::endl;
  }

  ~Foo() {
    std::cout << "destructing Foo at address " << this << std::endl;
  }
};

Using swig with python, I get the correct behavior:

>>> g = swigexample.Foo()
allocating a new Foo
>>> g = 1
destructing Foo at address: 0x2708b00

But with swig-matlab, the destructor seems to never be called, even when I clear mex or exit matlab.

>> x = swigexample.Foo()
allocating a new Foo
>> x = 1;
>> clear mex;
>> exit;

Is this an expected behavior? I see the same issue before and after f5532b8

[rdeits]

The problem seems to be that call to SWIG_Matlab_isOwned(argv[0]) inside the _wrap_delete_Foo function always returns false, so delete arg1 never occurs. Removing that check results in my objects being correctly deallocated.

[jaeandersson]

Hi! I'm back from vacation. This looks like a legit issue. Did you find a fix? If yes, feel free to make a pull request.

[rdeits]

I haven't yet. Overriding the call to SWIG_Matlab_isOwned to always return true trivially removes the immediate problem, but it seems likely to have unintended (dangerous) consequences later on. I'm not yet sure what the fundamental error is.

[jaeandersson]

OK. I have seen something similar with CasADi. I wanted to make another iteration on the design anyway, so hopefully a cleaner design will sort this out as well.

[rdeits]

Ok, sounds good. We'd love to be able to use this in Drake, so I'd be happy to help if I can. I don't have any experience with swig's internals, but can at the very least keep trying out whatever you have on our system.

[rdeits]

This seems to have been fixed in 269a408 Thanks!