Home Original page

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