New submission from Niklas Koep: I noticed that defining a new type where the tp_name field is NULL causes segfaults, for instance, when calling pydoc on the extension module. This particular segfault traces back to type_module() in Objects/typeobject.c where tp_name is passed to strrchr(). Raising an appropriate exception from PyType_Ready() seems sensible to avoid this kind of issue. The field is also used in two calls to PyErr_Format() in PyType_Ready() itself where it'll cause segfaults if not handled properly.
While we're on the subject, pydoc doesn't list the type documentation if the tp_name string does not have a dot in it. I didn't research this any further as omitting dots seems to be valid according to the docs. However, at the very least it seems like this side effect should be mentioned in the documentation to avoid confusion when someone omits/forgets the package.<subpackage>.module.type hierarchy in the field definition. I attached a tiny patch which just jumps to PyType_Ready()'s error label if the field is NULL. I also added a comment about pydoc in the two places of the documentation I could think of where tp_name is mentioned. ---------- components: Interpreter Core files: patch messages: 191705 nosy: nkoep priority: normal severity: normal status: open title: PyType_Ready() should sanity-check the tp_name field type: crash versions: Python 3.5 Added file: http://bugs.python.org/file30678/patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18287> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
