CPyExt errors with PyGObject

Issue #1434 resolved
Christoph Reiter created an issue

From (bugs.pypy.org)

Comments (22)

  1. Christoph Reiter reporter
    For future reference (since I've given up for now):
    
    - Checkout PyGObject git (I've tested 3.4/3.8, 3.4 has lower glib/gir
    dependencies if that's a problem)
    - Apply the following patches to make autotools work with PyPy:
     - https://bugzilla.gnome.org/show_bug.cgi?id=696646
     - https://bugzilla.gnome.org/show_bug.cgi?id=696648
     - https://bugzilla.gnome.org/show_bug.cgi?id=696650
    - Apply the attached patch that works around some limitations in cpyext.
    - Run the following to build against PyPy (a nightly build for example):
    
    PYTHON=/path_to_pypy/bin/pypy ./autogen.sh
    make
    
    - To run the tests:
    
    make check
    
    or better:
    
    SKIP_PEP8=1 make check.gdb (since it segfaults and pep8 tests are slow)
    
    The first segfault is because
    baseclass.tp_new(subclass, ...) # baseclass != subclass
    doesn't seem to work.
    
  2. Amaury Lepicard
    Do you have a gdb traceback?
    Also, last time I checked it was because pygobject_register_constants() uses a 
    type that is not yew PyType_Ready().
    I modified gobjectmodule.c and moved the call to pygobject_type_register_types() 
    before pygobject_register_constants()
    
  3. Christoph Reiter reporter
    As I said, there is no crash in pypy itself, but in pygobject, because tp_new
    returned an unexpected result.
    
    Am I missing something?
    
    Also, I won't spend time on this atm.. just wanted to make it easy for someone
    else to pick up where I left off.
    
  4. Amaury Lepicard
    A call to tp_new will return NULL in case of a Python exception.
    In this case the calling code should handle the error, and probably return 
    quickly.
    Where is this call to tp_new?
    
  5. Christoph Reiter reporter
    tp_new call: https://git.gnome.org/browse/pygobject/tree/gi/_gobject/pygenum.c#n39
    
    Ah, ok, thanks. The exception is: "type object 'PyGLibUserDirectory' has no
    attribute '__enum_values__'".. probably from pyg_enum_new below.
    
    Could it be that PyInt_Type.tp_new(int_subclass) calls new of the subclass
    instead of the PyInt one?
    
    .. I'm not that familiar with the Python C API.
    
  6. Amaury Lepicard
    I came to the same conclusion.  This is an old issue with our C API layer: there is only one 
    emulation of tp_new for all types provided by PyPy, and it does something like 
    subclass.__new__(args).
    The solution is to have a distinct tp_new for each type, which makes sense if you think about it.
    
    Here is a tentative patch; it's not finished: more tests are needed, and we should migrate all 
    slots emulation in this manner; but I fear that the (translated) code size explodes...
    
  7. mattip

    what is 'gi.FunctionInfo' ?

    To reproduce on Ubuntu 16.04 do I clone https://gitlab.gnome.org/GNOME/pygobject and pypy setup.py install; pypy -mpytest, or is there more I need to to?

  8. Christoph Reiter reporter

    It's PyGIFunctionInfo_Type which should have a tp_call, but I haven't looked into it.

    (since you mentioned it, pygobject supports Ubuntu 16.04)

  9. Christoph Reiter reporter

    It now fails at PyImport_ImportModule() which seems to do a relative import instead of an absolute one.

  10. Log in to comment