shogun modular interfaces with swig 3.x crashes

[vigsterkr]

all modular interfaces are crashing if swig 3.x is being used

[chengsoonong]

homebrew defaults to 3.0.2 at the moment. Here is how to downgrade:

$ brew versions swig
Warning: brew-versions is unsupported and will be removed soon.
You should use the homebrew-versions tap instead:
https://github.com/Homebrew/homebrew-versions

3.0.2 git checkout c484aac /usr/local/Library/Formula/swig.rb
3.0.1 git checkout c75e79a /usr/local/Library/Formula/swig.rb
3.0.0 git checkout d588f39 /usr/local/Library/Formula/swig.rb
2.0.12 git checkout 89eafbe /usr/local/Library/Formula/swig.rb
2.0.11 git checkout b51b660 /usr/local/Library/Formula/swig.rb
2.0.10 git checkout 4392eba /usr/local/Library/Formula/swig.rb
2.0.9 git checkout 0b50110 /usr/local/Library/Formula/swig.rb
2.0.8 git checkout ce2b082 /usr/local/Library/Formula/swig.rb
2.0.7 git checkout 4466cc1 /usr/local/Library/Formula/swig.rb
2.0.6 git checkout 293be9d /usr/local/Library/Formula/swig.rb
2.0.4 git checkout 0d8d92b /usr/local/Library/Formula/swig.rb

go to where the source is...

$ cd $(brew --prefix)

checkout old formula

git checkout 89eafbe /usr/local/Library/Formula/swig.rb
brew install swig

keep repository clean

git checkout -- Library/Formula/swig.rb

[karlnapf]

@tklein23 this might be of interest for you and your buddy

[karlnapf]

thanks @chengsoonong !

[besser82]

This actually affects me on upcoming fc21 as well… Let's see if we can come up with a fix for this…

[matthuska]

Just wanted to say that I'm using swig 3.0.2 with today's develop branch and the R modular interfaces and everything is working perfectly. gcc 4.8.2 in case that matters.

[vigsterkr]

ok so what's happening on my end is the following:
whenever a shogun object is being de-referenced in python i get a segfault with the following stacktrace:

* thread #1: tid = 0x8898ce, 0x00000001000c2b0e Python`PyArg_UnpackTuple + 126, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
  * frame #0: 0x00000001000c2b0e Python`PyArg_UnpackTuple + 126
    frame #1: 0x00000001032b0674 _modshogun.so`_wrap_delete_CSVFile(_object*, _object*) + 84
    frame #2: 0x00000001032ac758 _modshogun.so`_wrap_delete_CSVFile_closure(_object*) + 56
    frame #3: 0x0000000100065e92 Python`tupledealloc + 98
    frame #4: 0x00000001000b1120 Python`PyEval_EvalFrameEx + 19904
    frame #5: 0x00000001000ac052 Python`PyEval_EvalCodeEx + 1538
    frame #6: 0x0000000100037b6c Python`function_call + 364
    frame #7: 0x0000000100012033 Python`PyObject_Call + 99
    frame #8: 0x00000001000af980 Python`PyEval_EvalFrameEx + 13856
    frame #9: 0x00000001000ac052 Python`PyEval_EvalCodeEx + 1538
    frame #10: 0x00000001000aba46 Python`PyEval_EvalCode + 54
    frame #11: 0x00000001000d5884 Python`PyRun_FileExFlags + 164
    frame #12: 0x00000001000d5401 Python`PyRun_SimpleFileExFlags + 769
    frame #13: 0x00000001000eae98 Python`Py_Main + 3096
    frame #14: 0x00007fff8e8345c9 libdyld.dylib`start + 1

[vigsterkr]

ok so i've just compared the two cxx sources that were generated by swig2.0 and swig3.0.
basically what happens is the follow: swig3.0 adds the following line into the beginning of each wrapped method:

if(!PyArg_UnpackTuple(args,(char *)"new_CSVFile",0,0)) SWIG_fail;

so for example in case of CCSVFile, for the constructor it adds:

if(!PyArg_UnpackTuple(args,(char *)"new_CSVFile",0,0)) SWIG_fail;

and for the destructor it adds:

if(!PyArg_UnpackTuple(args,(char *)"delete_CSVFile",0,0)) SWIG_fail;

and in case of the destructor the passed args variable is NULL, hence the segfault.

[vigsterkr]

and it seems that this is something of a python feature of swig3.x as according to @matthuska the r modular interface generated by swig3.x works without any problems.