[issue14354] Crash in _ctypes_alloc_callback
New submission from Joe Rumsey : I have reproduced this crash in Apple's default 2.7.1 python, and in 2.7.3 built from source myself. But only in release mode. If I rebuild 2.7.3 in debug, the crash goes away. The attached file reproduces the issue, which has to do with a union containing multiple structs being used as a value for a callback argument. I've stripped it down as much as I can. Removing any fields from either the union or the Dice struct will cause this to no longer crash. The original source of this is libtcod's python wrapper library, which seems to work fine on platforms other than Mac, though it had a lot of other problems on 64-bit systems before I got to this one. This issue may also be more 64-bit specific than Mac specific. This is the callstack from Apple's python: #0 0x0001010c7712 in _ctypes_alloc_callback () #1 0x0001010c4a1c in PyCData_AtAddress () #2 0x000100050afa in icu::DigitList::getDouble () #3 0x0001bd32 in PyObject_Call () #4 0x00010008bf63 in ubrk_swap () #5 0x00010008ecd8 in triedict_swap () #6 0x00010008ed4d in triedict_swap () #7 0x0001000a608f in ucnv_openStandardNames () #8 0x0001000a614f in ucnv_openStandardNames () #9 0x0001000a72a2 in ucnv_getUnicodeSet () #10 0x0001000b72af in ucnv_getDisplayName () #11 0x00010e88 in ?? () -- assignee: ronaldoussoren components: Macintosh, ctypes files: testctypes.py messages: 156205 nosy: ogre, ronaldoussoren priority: normal severity: normal status: open title: Crash in _ctypes_alloc_callback type: crash versions: Python 2.7 Added file: http://bugs.python.org/file24919/testctypes.py ___ Python tracker <http://bugs.python.org/issue14354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14354] Crash in _ctypes_alloc_callback
Joe Rumsey added the comment:
I just built python 3.2.2 from source, and reproduced the issue there as well.
Same location. Here's the slightly more informative stack trace from my
release-with-symbols 3.2.2 build:
#0 _ctypes_alloc_callback (callable=0x7fff5fbfef20, converters=0x10003,
restype=0x7fff5fbfef20, flags=1606414112) at callbacks.c:432
#1 0x0001010c5395 in PyCFuncPtr_new (type=0x7fff5fbfefc0,
args=0x101010580, kwds=0x7fff5fbfefc0) at _ctypes.c:3372
#2 0x00010004986c in type_call (type=0x1006ca940, args=0x101041b90,
kwds=0x0) at typeobject.c:676
#3 0x00018605 in PyObject_Call (func=0x1006ca940, arg=0x101041b90,
kw=0x0) at abstract.c:2149
#4 0x00010008afcc in do_call [inlined] () at
/Users/ogre/src/Python-3.2.2/Python/ceval.c:4141
#5 0x00010008afcc in PyEval_EvalFrameEx (f=0x7fff5fbff1c0,
throwflag=1606414784) at ceval.c:3944
#6 0x00010009131b in PyEval_EvalCodeEx (_co=0x7fff5fbff260, globals=0x0,
locals=0x1066c880101, args=0x7fff5fbff260, argcount=1606414944,
kws=0x7fff5fbff260, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0)
at ceval.c:3350
#7 0x00010009139f in PyEval_EvalCode (co=0x101066828, globals=0x101066c88,
locals=0x0) at ceval.c:767
#8 0x0001000b0a21 in run_mod [inlined] () at
/Users/ogre/src/Python-3.2.2/Python/pythonrun.c:1783
#9 0x0001000b0a21 in PyRun_FileExFlags (fp=0x7fff7c677ee0,
filename=0x101066828 "\002", start=0, globals=0x101066c88, locals=0x0,
closeit=1, flags=0x7fff5fbff420) at pythonrun.c:1740
#10 0x0001000b2992 in PyRun_SimpleFileExFlags (fp=0x7fff7c677ee0,
filename=0x10104ac20 "testctypes.py", closeit=1606415200, flags=0x7fff5fbff360)
at pythonrun.c:1265
#11 0x0001000c45af in run_file [inlined] () at
/Users/ogre/src/Python-3.2.2/Modules/main.c:297
#12 0x0001000c45af in Py_Main (argc=1606415440, argv=0x7fff5fbff450) at
main.c:692
#13 0x00011522 in main (argc=17197096, argv=0x100609fe0) at python.c:59
converters doesn't seem to be pointing at valid data.
(gdb) p *converters
$2 = {
ob_refcnt = 3302829852670,
ob_type = 0xe000200
}
But, being an optimized build, it's hard to say (especially for me, having
never debugged python itself before) if that's the real data or some
optimizer-mangled version.
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue14354>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14354] Crash in _ctypes_alloc_callback
Joe Rumsey added the comment: Thanks for that. This does seem to be the case. I rebuilt with CC=gcc-4.2 and my short sample and the full library I took it from both work fine. -- ___ Python tracker <http://bugs.python.org/issue14354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14354] Crash in _ctypes_alloc_callback
Joe Rumsey added the comment: It's maybe not directly relevant to fixing this, but I worked around it on the project where this came up by redefining dice as (c_int * 4) and col as (c_uint8 * 3) in the union, then using ctypes.cast to get those as pointers to the actual struct. That seems to work just fine for now. -- ___ Python tracker <http://bugs.python.org/issue14354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
