Hi Roger, On Mon, May 2, 2011 at 6:55 AM, Roger Binns <rog...@rogerbinns.com> wrote: > The pypy site also doesn't say where to communicate for cpyext - I assumed > this mailing list was the right place.
Yes. > static PyObject *themodule=Py_InitModule3(...); > > Later in one of the methods called back from Python I call > PyObject_AttrString(themodule, "foo") which is crashing. If I incref > themodule in init then this problem doesn't occur. Indeed, it's an edge case. What you must realize is that your module object is of course kept alive in PyPy, even if its refcount drops to zero. More precisely, in PyPy, every object accessed by the C extensions is actually accessed via a "wrapper", which is declared as PyObject. A wrapper holds just the refcount and a reference to the real object, which is not a PyObject at all (it's an object that can be moved by our GC, to start with). When the refcount drops to zero we assume that the C extension doesn't need the object any more, and we free the PyObject wrapper. This may or may not cause the real object within PyPy to be freed. It may even be the case that later we want again to pass a reference to the same object to the C extension; in this case, we make a new wrapper. So the refcount of -- in your case -- the module object is never zero; it's just that as soon as the main function of your C extension module finishes, the refcount is decremented and reaches zero, so the PyObject wrapper is freed. It is arguably a bug in your module, even though in that case it is hard to write an example that triggers the bug, because it is impossible in CPython to free a loaded extension module. The point is that if it is was possible, then doing so in CPython would cause the module to see its refcount drop to zero, and be freed, which makes the pointer in the static global variable invalid. That's what I meant by saying that such issues are, somehow, showing bugs in the C extension module, although admittedly they are often "bugs" that cannot possibly cause an issue in practice. A bientôt, Armin. _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
