Hello,
The only Analysis (rather than Python) function that is mentioned is
init_Py_Gl_handler, which is the first function going into the C world
that is called (indirectly) by a specific Python function. Assuming that
that stack trace is complete and correct, then it's hard to see why it's
crashing in that function since not a heck of a lot happens there except a
call to a Python C function and then a call to an Analysis proper (i.e.
unrelated to Python) C function. And if you believe that stack trace then
the crash didn't happen inside either of those two functions. The
remaining lines of code are about as innocuous as you can get.
static PyObject *init_Py_Gl_handler(PyObject *self, PyObject *args)
{
PyObject *widget;
#ifdef USE_GL_TRUE
int direct = GL_TRUE;
#else
int direct = GL_FALSE;
#endif
if (!PyArg_ParseTuple(args, "O|i", &widget, &direct))
RETURN_OBJ_ERROR("must have one argument: widget");
return new_py_gl_handler(widget, direct ? CCPN_TRUE : CCPN_FALSE);
}
Wayne
On Mon, 12 Feb 2007, Murali Vadivelu wrote:
> Date/Time: 2007-02-12 17:12:15.562 +0000
> OS Version: 10.4.8 (Build 8L127)
> Report Version: 4
>
> Command: python2.5
> Path: /sw_10.4/bin/python2.5
> Parent: sh [22787]
>
> Version: ??? (???)
>
> PID: 22788
> Thread: 0
>
> Exception: EXC_BAD_ACCESS (0x0001)
> Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
>
> Thread 0 Crashed:
> 0 <<00000000>> 0x00000000 0 + 0
> 1 GlHandler.so 0x0284b54c init_Py_Gl_handler + 252
> 2 python2.5 0x00020474 PyObject_Call + 52 (abstract.c:1861)
> 3 python2.5 0x0009dfe8 PyEval_EvalFrameEx + 20328 (ceval.c:
> 3848)
and a lot more...
|