Py_XDECREF() causes segmentation fault in _call_function_pointer()

Hi. We are consistently getting a segmentation violation in _ctypes.so
in _call_function_pointer() for a specific function.

The problem disappears if I comment out statement
"Py_XDECREF(error_object)" in callproc.c _call_function_pointer().

error_object is NULL when seg fault occurs so Py_XDECREF(error_object)
should effectively be doing nothing yet causes a seg fault.

 

** I'm not very familiar with mips assembler or backtraces and would
like to understand *why* this problem occurred and find out if there is
an "official" fix or workaround.

 

The problem function looks like:

int myfunc( tHandle handle, tNames name, void* pValue ) where "typedef
void* tHandle" and "typedef enum { ... } tNames"

 

so the corresponding python/ctypes call looks like

mylib = ctypes.CDLL('/lib/mylib.so')

c_value = ctypes.c_uint16( 0x00 )

mylib.myfunc( ctypes.c_void_p( 1 ), c_int( 4 ), ctypes.cast(
ctypes.byref( c_value ), ctypes.c_void_p ) )

<< note: if it looks strange to init a void* to a 1, this is done
because parm type was is declared as "typedef void* tHandle" and this
handle was effectively implemented as an integer, not a pointer to a
structure as you might expect >>

 

Platform is embedded MIPS (big-endian). _ctypes is from
Python-2.6.1.tar.bz2.

_call_function_pointer() in callproc.c seg faults at the
"Py_XDECREF(error_object)" statement at line 834, specifically "lw" at
offset 126e4 in objdump below. 

The error_object pointer is NULL at the time "Py_XDECREF(error_object)"
is called since "flags" parm is 0x1101, ie: neither FUNCFLAG_USE_ERRNO
or FUNCFLAG_USE_LASTERROR are set.

I believe commenting it out doesn't affect program logic in this case
since error_object is NULL so nothing needs to happen: "#define
Py_XDECREF(op) if ((op) == NULL) ; else Py_DECREF(op)".

 

  16:25:59 |
/home/jdama/ccm_wa/atl_client_db/CTA5/Plat/oe/out/work/mips-linux/python
-2.6.1-ml5/Python-2.6.1/Modules/_ctypes/callproc.c:832

  16:25:59 |    126d8:    ae040000    sw  a0,0(s0)

  16:25:59 |
/home/jdama/ccm_wa/atl_client_db/CTA5/Plat/oe/out/work/mips-linux/python
-2.6.1-ml5/Python-2.6.1/Modules/_ctypes/callproc.c:834

  16:25:59 |    126dc:    12400006    beqz    s2,126f8 <_CallProc+0x414>

  16:25:59 |    126e0:    00000000    nop

=>16:25:59 |    126e4:    8e420000    lw  v0,0(s2)

  16:25:59 |    126e8:    00000000    nop

  16:25:59 |    126ec:    2442ffff    addiu   v0,v0,-1

  16:25:59 |    126f0:    10400065    beqz    v0,12888 <_CallProc+0x5a4>

  16:25:59 |    126f4:    ae420000    sw  v0,0(s2)

  16:25:59 |
/home/jdama/ccm_wa/atl_client_db/CTA5/Plat/oe/out/work/mips-linux/python
-2.6.1-ml5/Python-2.6.1/Modules/_ctypes/callproc.c:836

  16:25:59 |    126f8:    16a0004f    bnez    s5,12838 <_CallProc+0x554>

  16:25:59 |    126fc:    00000000    nop

 

DIAG 0x0b: Cause: 0x0b - SIGSEGV: Segmentation violation

DIAG 0x0b: Reason: code 0x80, Sent by kernel

DIAG 0x0b: Thread: 5066720 - "", Priority: 5066552, AppID: 0

DIAG 0x0b: Backtrace: 2b2f66e4 _CallProc+0x400

                      2b2f687c _CallProc+0x598

                      

MMAP: 2b2e4000-2b303000 r-xp 00000000 00:0d 336528
/usr/lib/python2.6/lib-dynload/_ctypes.so

MMAP: 2b303000-2b342000 ---p 0001f000 00:0d 336528
/usr/lib/python2.6/lib-dynload/_ctypes.so

MMAP: 2b342000-2b345000 rw-p 0001e000 00:0d 336528
/usr/lib/python2.6/lib-dynload/_ctypes.so

 

2b2f66e4 - 2b2e4000 = 126E4

 

Thanks,

John Dama

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
ctypes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ctypes-users