~Environment

Cross compiled Python 2.7.15 for ARM Cortex-A7 target, Linux Kernel 4.18

uname -a: Linux Test-0002 4.18.13 #1 SMP Wed Oct 31 11:20:07 CET 2018 armv7l GNU/Linux

~Description of the problem

Importing the "ctypes" module in order to load shared libraries causes a segmentation fault:

root [ /tmpfs/root ] $ python
Python 2.7.15 (default, Nov 29 2018, 13:57:56)
[GCC 8.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
Segmentation fault

I have found a similiar issue here:
https://bugs.python.org/issue11048
But the changes are already applied in 2.7.15.

Here is the GDB output similiar to the link I posted:

(gdb) file python2.7
Reading symbols from python2.7...done.
(gdb) run -c "import ctypes"
Starting program: /usr/bin/python2.7 -c "import ctypes"
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.

Program received signal SIGSEGV, Segmentation fault.
0x76a4fa94 in CThunkObject_dealloc (_self=0x76adb920) at /home/user/ARM_Linux/src/Python-2.7.15/Modules/_ctypes/callbacks.c:25
25      /home/user/ARM_Linux/src/Python-2.7.15/Modules/_ctypes/callbacks.c: No such file or directory.
(gdb)

From what I can see it tries to use the path from the host I cross compiled for the callbacks.c. Is this the cause of the segmentation fault? If yes, how can I correct the path during compilation?

I also attached the strace log of the command 'python -c "import ctypes"'

Thank you in advance!

Small update:

After commenting out Py_XDECREF(self->restype) in function CThunkObject_dealloc(PyObject *_self), I can import ctypes without getting a segmentation fault.

static void
CThunkObject_dealloc(PyObject *_self)
{
    CThunkObject *self = (CThunkObject *)_self;
    PyObject_GC_UnTrack(self);
    Py_XDECREF(self->converters);
    Py_XDECREF(self->callable);
    //Py_XDECREF(self->restype);
    if (self->pcl_write)
        ffi_closure_free(self->pcl_write);
    PyObject_GC_Del(self);
}

But I'm afraid I don't know what other effects could result with this change.

Another small update:

After I recompiled Python with the commented out statement, I did a small test if loading a shared library works.

I compiled the following test function to testib.so:

#include <stdio.h>

void test_func(void);

void test_func(void) {
	printf("hello world\n");
}

After that I used ctypes to load this library and execute the test_func():

(gdb) file python2.7
Reading symbols from python2.7...done.
(gdb) run -c "import ctypes; lib_test = ctypes.cdll.LoadLibrary('/tmp/testlib.so'); lib_test.test_func();"
Starting program: /usr/bin/python2.7 -c "import ctypes; lib_test = ctypes.cdll.LoadLibrary('/tmp/testlib.so'); lib_test.test_func();"
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
hello world

Program received signal SIGSEGV, Segmentation fault.
PyCFuncPtr_call (self=<optimized out>, inargs=<optimized out>, kwds=<optimized out>) at /home/user/ARM_Linux/src/Python-2.7.15/Modules/_ctypes/_ctypes.c:4108
4108    /home/user/ARM_Linux/src/Python-2.7.15/Modules/_ctypes/_ctypes.c: No such file or directory.
(gdb)

It prints the expected output, but again I get a segmentation fault, this time in PyCFuncPtr_call function.