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. _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev