On 10 December 2012 19:21, William Fulton wrote:
>
> On 10/12/12 11:13, Kris Thielemans wrote:
> >> From: William Fulton
> >> Sent: 06 December 2012 20:57
> >>
> >> On 05/11/12 05:02, Kris Thielemans wrote:
> >>> Hi
> >>>
> >>> I'm trying to use SWIG to wrap our C++ library. This has worked great
> > for
> >>> Python (work in progress of course) and I've now had a look at Octave
> >> (using
> >>> the same .i file).
> >>>
> >>> I first had to modify swig/Source/Modules/octave.cxx to add a line
> >>> Preprocessor_define((DOH *) "SWIG_CPLUSPLUS_CAST", 0);
> >>> Otherwise, the generated code didn't compile. I'll submit this as a
bug
> > with
> >>> an easy patch.
> >>>
> >>> More serious however are the problems I encounter when I use
> >>> boost_shared_ptr.i. In summary, the way that the wrapped code works
> has
> >>> problems with accessing the members of a shared_ptr, see below. I
> seem
> >> to be
> >>> able to fix this by modifying boost_shared_ptr.i as attached, i.e.
> >>> replacing all occurrences of
> >>> $descriptor(SWIG_SHARED_PTR_QNAMESPACE::shared_ptr< TYPE >
> >> *)
> >>> by
> >>> $descriptor(TYPE *)
> >>>
> >>> That seems rather scary though. Anyone any experience with this?
> >> I really have no idea how good the octave support for shared_ptr is.
The
> >> initial commit of Lib/octave/boost_shared_ptr.i mentions that partial
> >> support was added for boost::shared_ptr by Xavier. I developed the
> >> Python/Java/C# versions and it is time consuming getting it right. I
> >> would diff the file with the python version which is good because I'd
> >> imagine the typemaps would be identical and any other problems will be
> >> in the runtime system which I'm afraid probably requires a volunteer
> >> like yourself to debug and fix.
> >>
> >
> > Thanks William
> >
> > I haven't encountered any problems with this yet, but haven't done any
> > extensive testing at all. In fact, I'm not 100% sure how I would test it
> > (aside from not seeing any run-time errors). Maybe I could use valgrind
to
> > see if there's any memory leaks? I have done that now but unfortunately
> > there development octave version that I'm running has memory leaks
itself
> so
> > it's not entirely straightforward to test this. I do see a few small
leaks
> > in the swig-octave run-time (which I don't have time to look into), and
a
> > few from calling my code (which surprised me). No major leaks with any
of
> > the shared_ptr though.
> >
> > In any case, without my suggested fix, the code doesn't run at all,
which is
> > arguably worse than having a memory leak :-)
> >
> > So, I'll submit a bug report with the patch then.
> There is some testing mechanism in the test-suite for this. See
> SHARED_PTR_WRAPPER in li_boost_shared_ptr.i. You can check and
> compare
> with Java / Python for which this was originally developed. I strongly
> recommend porting the Java or Python version to Octave as it took quite
> some effort to put this test in place and it'll be a lot easier to port
> it to Octave than to re-invent something similar.
>
Hi
I looked into this a bit more before submitting the bug report. First a
comment on my proposed fix, which was to modify octave/boost_shared_ptr.i by
replacing all occurrences of
$descriptor(SWIG_SHARED_PTR_QNAMESPACE::shared_ptr< TYPE >*)
by
$descriptor(TYPE *)
I did a diff with python/boost_shared_ptr.i and its virtually identical to
the octave version (aside from some null_deleter stuff and a few lines that
were updated for python but not yet for octave. I've updated those in the
attachment otherwise the test code below doesn't compile).
That seems to tell me that octave/boost_shared_ptr.i is probably ok, but
that it's the $descriptor stuff that's broken, or yet something else. I
don't really know I'm afraid. Any ideas?
In any case, I proceeded with my proposed mods and followed your suggestion
and took li_boost_shared_ptr_runme.py and made it into an octave version.
It's attached here. (To run the test, you obviously also need to change
li_boost_shared_ptr.i to enable the code when SWIG_OCTAVE is defined.)
The good news is that most of these tests run fine! There's a few that I had
to disable as I don't know what to use for Python's None in octave. However,
there's still a few tests that crash octave. I've commented them out in the
attached (and flagged with "CRASH HERE"). The first one that fails is as
follows:
# //////////////////////////////// Derived and base class mixed
////////////////////////////////////////
# pass by shared_ptr (mixed)
k = KlassDerived("me oh my");
fprintf('CRASH AFTER THIS\n');
kret = smartpointertest(k);
fprintf('CRASH BEFORE THIS\n');
Running octave from in gdb and executing the test shows that it crashes in
smartpointertest (of course...). The relevant bit looks of the wrapped code
is as follows
int newmem = 0;
res1 = SWIG_ConvertPtrAndOwn(args(0), &argp1, SWIGTYPE_p_Space__Klass,
0 , &newmem);
if (!SWIG_IsOK(res1)) {
SWIG_exception_fail(SWIG_ArgError(res1), "in method '"
"smartpointertest" "', argument " "1"" of type '" "SwigBoost::shared_ptr<
Space::Klass >""'");
}
if (argp1) arg1 = *(reinterpret_cast< SwigBoost::shared_ptr<
Space::Klass > * >(argp1));
//snip...
result = Space::smartpointertest(arg1);
Investigating this a bit closer shows that something is wrong with arg1, as
it points to ill-defined memory. So, presumably there's something wrong with
the above casting. Note that this cast is of course one that I changed with
the mods above.
This is about as far as I can get with this I'm afraid.
Any suggestions anyone?
Kris
|