(trying again)
"Saravanan D" wrote:
> > > 03 023ffaa4 1e013182 00000000 055b1250 00637470 python23!cmp_outcome(int
> op
> > > = 88026108, struct _object * v = 0x00000001, struct _object * w =
> > > 0x00000000)+0xa9 [F:\Python-2.3.3\Python-2.3.3\Python\ceval.c @ 3880]
> > > 04 023ffb18 1e016ba4 014f3318 00000002 0099f170
> python23!eval_frame(struct
> > > _frame * f = 0x053f2bfc)+0x542
> [F:\Python-2.3.3\Python-2.3.3\Python\ceval.c
> > > @ 1965]
> > > 05 023ffb30 1e016a69 0099f170 023ffb7c 00000002
> > > python23!fast_function(struct _object * func = <Memory access error>,
> struct
> > > _object *** pp_stack = <Memory access error>, int n = <Memory access
> error>,
> > > int na = <Memory access error>, int nk = <Memory access error>)+0x94
> >
> > the above doesn't look very healthy. does your application involve
> > non-standard extensions (including extensions you've written your-
> > self)? does the extensions contain callbacks into Python code?
> >
>
> My application uses extension modules which devliers the callbacks to Python
> Code. Im using SWIG 1.3.19 version to generate relevant python interfaces
> for the C++ code.
how are you accessing the callbacks? if you're doing that from threads
created at the C++ level, you must make sure that the thread state is
properly set up. see:
http://www.python.org/doc/2.4.1/api/threads.html
if you're registering the callbacks from Python (via SWIG:ed "register"
calls), you must keep track of the thread state, so that callbacks run
in the same state as they were registered in.
</F>
--
http://mail.python.org/mailman/listinfo/python-list
