shogun modular interfaces with swig 3.x crashes #2313

Open
vigsterkr opened this Issue Jun 16, 2014 · 8 comments

Comments

Projects
None yet
5 participants
@vigsterkr
Member

vigsterkr commented Jun 16, 2014

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

@vigsterkr vigsterkr self-assigned this Jul 20, 2014

@vigsterkr vigsterkr changed the title from python modular interface is broken on OSX to shogun modular interfaces with swig 3.x crashes Jul 21, 2014

@chengsoonong

This comment has been minimized.

Show comment
Hide comment
@chengsoonong

chengsoonong Jul 31, 2014

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

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

This comment has been minimized.

Show comment
Hide comment
@karlnapf

karlnapf Aug 1, 2014

Member

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

Member

karlnapf commented Aug 1, 2014

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

@karlnapf

This comment has been minimized.

Show comment
Hide comment
Member

karlnapf commented Aug 1, 2014

thanks @chengsoonong !

@besser82

This comment has been minimized.

Show comment
Hide comment
@besser82

besser82 Aug 1, 2014

Member

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

Member

besser82 commented Aug 1, 2014

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

@matthuska

This comment has been minimized.

Show comment
Hide comment
@matthuska

matthuska Aug 14, 2014

Contributor

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.

Contributor

matthuska commented Aug 14, 2014

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 vigsterkr added this to the Shogun 3.4 milestone Sep 2, 2014

@vigsterkr vigsterkr modified the milestones: Shogun 3.4, SHOGUN 3.2.1 Oct 25, 2014

@MartinHjelm MartinHjelm referenced this issue in Homebrew/homebrew-science Oct 27, 2014

Closed

shogun: 'jni.h' file not found #217

@vigsterkr

This comment has been minimized.

Show comment
Hide comment
@vigsterkr

vigsterkr Oct 31, 2014

Member

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
Member

vigsterkr commented Oct 31, 2014

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

This comment has been minimized.

Show comment
Hide comment
@vigsterkr

vigsterkr Oct 31, 2014

Member

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.

Member

vigsterkr commented Oct 31, 2014

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

This comment has been minimized.

Show comment
Hide comment
@vigsterkr

vigsterkr Oct 31, 2014

Member

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.

Member

vigsterkr commented Oct 31, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment