The enum_type_object type inherits from PyLong_Type which is not tracked
by the GC. Instances doesn't have to be tracked by the GC: remove the
Py_TPFLAGS_HAVE_GC flag.
The Python C API documentation says:
"To create a container type, the tp_flags field of the type object
must include the Py_TPFLAGS_HAVE_GC and provide an implementation of
the tp_traverse handler."
https://docs.python.org/dev/c-api/gcsupport.html
The new exception was introduced in Python 3.11 by:
https://github.com/python/cpython/issues/88429
PyLong_Type raises an exception if the argument is not convertible to
long, therefore, this has to be handled as new_reference and not
new_non_null_reference, otherwise a segfault will occur.
This adds a missing return statement in the python3 specific
import logic of boost.python.numpy.
For python3 wrap_import_array() needs to return a pointer value.
The import_array() macro only returns NULL in case of error. The
missing return statement is UB, so the compiler can assume it does
not happen. This means the compiler can assume the error branch
is always taken, so import_array must always fail.
Line no 138-139 suggest if condition satisfy if n_actual <=max_arity :
if (n_actual + f->m_nkeyword_values >= min_arity
&& n_actual <= max_arity)
So condition at Line no 161 is not reachable.
Python 3.7 changes the return type of _PyUnicode_AsString()
from void* to const char* -- causing the build of boost-python
to fail.
Signed-off-by: Bernhard Rosenkränzer <bero@lindev.ch>
Unfortunately due to optimised build of Python3 libraries and executable I got only partial stack from [http://clang.llvm.org/docs/AddressSanitizer.html], however digging into and reducing my code I tracked it down to be issue with `boost/libs/python/src/object/enum.cpp`.
It has to bits that leak (and comment mentioning there is one):
PyObject *mod = PyObject_GetAttrString( self_, "__module__");
Leaks reference, as it never decreases it.
It also stores a new string object under object's `name` that ref count never gets decremented.
That commit fixes both issues.
Many times the caller may have a string created in C++,
so there is no need to wrap it in a Python object when
the only thing done with the object is extract<char*>.
