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