- This reverts commit 931656bcbe
- Since atexit() does not pass along the desired exit status,
__swig_atexit__() always exits with status zero, regardless
of whether Octave completed successfully or raised an error.
- This means the success/failure of Octave scripts which load
SWIG modules cannot be determined by other programs, which
makes them unusable.
- Instead, provide a Octave function swig_exit() which calls
::_Exit() with a given exit status. This way at least a
clean exit from Octave can be guaranteed for future versions
if the seg-fault problem is not fixed.
- The {DECLARE|DEFINE}_OV_TYPEID_FUNCTIONS_AND_DATA declarations
attached to this class cause a seg-fault in the module_load
Octave example. Removing these declarations fixes the seg-fault.
- While cause of seg-fault is unknown, note that (in Octave 5.1.0)
the declaration of octave_function, which is the base class for
octave_swig_bound_func, does not use these declarations. So it's
possible they simply are not required for this type of subclass.
When wrapping STL containers, remove a shared_ptr reference count
increment when an upcast is needed when checking type conversion
in traits_check::check.
* master-fix-vector-shared_ptr:
fixing memleak of shared_ptr objects in python with creating a [wrapped] vector<shared_ptr<Foo>> from a list of shared_ptr<Bar> where Bar is derived from Foo.
If python_append.i is modified to use:
__slots__ = []
instead of
__slots__ = ["this"]
then this additional error checking prevents a crash and shows a stack trace and error:
AttributeError: 'ForSlots' object has no attribute 'this'
Related to issue #1674
Don't attempt to use the class's __dict__ for setting 'this' when
a user has extended a class with:
__slots__ = ['this'].
Was segfaulting. Now we fall back to a simple PyObject_SetAttr if the
usual approach to setting 'this' in __dict__ does not work.
Closes#1673Closes#1674
There is a possible memory leak in case the SWIG_exception_fail macro
is called. The problem is related to its definition that call the
function Rf_warning. This function (as well as Rf_error) involves
a longjmp over C++ destructors on the stack. Thus, all the objects
allocated on the heap are not freed.
Closes#914
Instead of silenty ignoring them, now a "TypeError: f() takes no keyword arguments"
exception is thrown if keyword arguments are used. Hence constructors and normal
methods/functions behave in the same way.
Closes issue #1595
The macros for casting function pointers are now fully described and also
clarify why the macros act transparently for C even before Ruby 2.7.
In addition, an "if (CPlusPlus)" was removed in the code generator for
global variables in order to keep the distinction between C and C++ in
one place, which is at the definition of said macros.
This commit fixes the signatures of various callback methods
and cleans up the macro definitions used for casting callbacks.
Note that the transparent version of the macro RUBY_METHOD_FUNC
is currently masked behind RUBY_DEVEL, see commit
1d91feaf13
In order to still support strict signature checking and prevent
nasty deprecation warnings, the use of RUBY_METHOD_FUNC had to
be replaced with VALUEFUNC.
The type long may be 4 bytes but swig_this() must return the address of
the object as an integer. Using size_t ensures that the return type can
store a pointer.
