[cable] generated python wrapper signals EXC_BAD_ACCESS on MacOSX

[Kaben Nanlohy]

The short answer : PyErr_Occurred () at Python/errors.c:81 is just the
end of the function. That is, I think, PyErr_Occurred () doesn't
remember how/where to return.

Of course, this information is less than useful. I haven't found the
start of the clobbering -- this Python executable is optimized, and I'm
not good at debugging optimized code. I hope for more insight when I
compare the swig-only object construction, and I may have better luck
with an unoptimized Python.

-- K


On Mon, 9 Feb 2004, Brad King wrote:

> I have not seen this error before.  There are a few things to do for 
> starters.  Please obtain the python2.3 source (I think fink puts it 
> somewhere like /sw/sources on your disk) and extract it.  Then use 
> symlinks in your build tree to help it find the debugging symbols. 
> Hopefully this will reveal what is going wrong inside PyErr_Occurred().
> 
> You might also want to use gdb to step through the object construction 
> in the swig-only version you report that works.  Then you can compare 
> the call to PyObject_CallObjectWithKeywords side-by-side between the two 
> examples.
> 
> -Brad
> 
> Kaben Nanlohy wrote:
>
> > Running python2.3 from gdb (this may not be a good way to debug -- I am no
> > python expert), I see:
> > 
> > >>>b=bar()
> > 
> > Program received signal EXC_BAD_ACCESS, Could not access memory.
> > PyErr_Occurred () at Python/errors.c:81
> > 81      Python/errors.c: No such file or directory.
> >         in Python/errors.c
> > (gdb) bt           
> > #0  PyErr_Occurred () at Python/errors.c:81
> > #1  0x013497f4 in PyObject_Call (func=0x1442af0, arg=0x0, kw=0x13497f4) at Objects/abstract.c:1756