[pypy-dev] cpyext: Detecting pypy and other issues

Armin Rigo arigo at tunes.org
Sat May 14 17:20:27 CEST 2011


Hi Roger,

Ah, sorry.  I think I got mistaken in my previous mail.  The point is
that you are debugging *only* a C extension, and not interested in
debugging any of the rest of PyPy.  Then all we said about GCs makes
no sense: the PyObject* within PyPy are not handled by PyPy's GC.
They are normally malloc()ed and free()d --- except that, maybe for no
good reason any more, we redirect malloc() and free() to obmalloc.c,
which is very similar to CPython's PyObject_Malloc.  You disable it
with "make no_obmalloc", and then they are just normal malloc()ed and
free()d objects from the C point of view.  This is independent of the
GC, which anyway only handles the objects that are in native RPython
format.

Similarly, you don't want a gdb macro that nicely prints any RPython
object.  You want instead a macro that nicely prints a PyObject* from
cpyext.  Sorry, I missed this.  And indeed, you can probably just call
PyString_AsString(PyObject_Repr(x)) from gdb to get it.  In fact, the
same gdb macro that works on CPython has chances to work on PyPy ---
or it would if we had _PyObject_Dump() in cpyext.

Note that the objects that C extension modules see are "placeholder"
PyObjects, that indirectly contain a reference to the "real" RPython
object.  There are no memory optimisations that should interfere with
PyObjects; for example, no free list.  I'm pretty sure that the
troubles you get are simply due to the placeholders being freed too
early.  The difference with CPython is that the reference count in the
placeholder only counts references from the C extension, and not the
references that would, in CPython, be taken from other parts of the
interpreter.  That's why placeholder PyObjects can go away earlier in
PyPy than normal PyObjects in CPython.  That's the case for which
adding a debugging mode in PyPy would be useful.


A bientôt,

Armin.


More information about the pypy-dev mailing list