Message76078
This is difficult: the backtrace only show plain python operations.
Some hints though:
One backtrace shows a memory corruption in the obmalloc data. This may come from a
buffer overrun.
You initially selected ctypes in "Components", does this mean that your program
also use ctypes?
With ctypes it is easy to be caught with a python string converted to a (mutable)
char* pointer.
For example, on Windows:
>>> import ctypes
>>> c = ctypes.CDLL('msvcrt')
>>> a = " "
>>> c.strcpy(a, "X" * 50)
50
>>> a
'XXXX'
... and the crash is not far.
Another case of corruption in obmalloc is to try to allocate python objects while
the GIL is not held. This may happen if you wrote a C function that uses the
Python API, and call this with ctypes.
In any case, I suggest that you build and a use a debug-enabled version of python
(configure with --with-pydebug). It catches some errors earlier and sometimes more
reliably. |
|
Date |
User |
Action |
Args |
2008-11-19 23:15:04 | amaury.forgeotdarc | set | recipients:
+ amaury.forgeotdarc, farshad |
2008-11-19 23:15:04 | amaury.forgeotdarc | set | messageid: <1227136504.32.0.564190405144.issue4358@psf.upfronthosting.co.za> |
2008-11-19 23:15:03 | amaury.forgeotdarc | link | issue4358 messages |
2008-11-19 23:15:02 | amaury.forgeotdarc | create | |
|