Embedding: How to set globals for PyObject_Call
Michael Hudson
mwh at python.net
Fri Feb 22 05:52:43 EST 2002
xscottgjunk at yahoo.com (Scott Gilbert) writes:
> Michael Hudson <mwh at python.net> wrote:
> > xscottgjunk at yahoo.com (Scott Gilbert) writes:
> >
> > > // This one breaks
> > > Var g = VarEval("globals");
> > > g(); // This causes a segfault
> >
> > Do we get to see the backtrace?
> >
>
> - For "globals", it segfaults in builtin_globals(...) where it tries
> to Py_INCREF the null result from PyEval_GetGlobals(). The dbx stack
> trace is below if you really want it. :-)
>
> - For "locals", it segfaults when trying to Py_INCREF the null return
> result from PyEval_GetLocals(). Similar stack trace as below, but
> this is on line 1104 of bltinmodule.c
>
> - For "vars", it sets up a Python error of "no locals!?" on line 1992
> of bltinmodule.c
>
> - Finally for "dir", PyObject_Dir [object.c, 2085] is called from
> builtin_dir [bltinmodule.c, 1992] and returns a null, but doesn't
> setup the Python error, so up the call stack PyObject_Call sets up a
> system error of "NULL result without error in PyObject_Call"
> [abstract.c, 2034].
Oh, I see what's going on. Another question: what would you expect
locals() to return?
> Many other functions work without a hitch. (For instance, "list" is a
> builtin that can take no args, and I correctly get a new list object
> when I do my equivalent of apply() on that.)
Yeah, but they don't access the frame of the calling (presumed Python)
function.
> Well, I hope this is sufficient info if you view this as enough of a
> problem to fix it. Thanks for your interest.
It's probable that Python shouldn't core in these circumstances, at
least.
Cheers,
M.
--
There are two kinds of large software systems: those that evolved
from small systems and those that don't work.
-- Seen on slashdot.org, then quoted by amk
More information about the Python-list
mailing list