This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: subclassing ModuleType and another built-in type
Type: Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: arigo, mwh
Priority: normal Keywords:

Created on 2005-04-01 09:22 by arigo, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg24842 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2005-04-01 09:22
class X(types.ModuleType, str): pass
X('name')
-> segfault

This buggy subclassing goes through typeobject.c's checks because PyModuleObject looks exactly like a user-defined subclass of 'object': it has a PyObject_HEAD followed only by the dict, as specified by tp_dictoffset.

A fix would be to forbid any subclassing to move the tp_dictoffset of a non-heap type.
msg24843 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2005-04-02 12:27
Logged In: YES 
user_id=4771

The proposed fix is not good enough.  If another built-in C type similar to PyModuleObject is defined (say by a C extension module), then it would become possible to subclass both this new type and ModuleType.  This might lead to unwanted behavior if e.g. one parent class allows rebinding __dict__ and the other not (and crashes if __dict__ is rebound).

This might point to the need for cleaning up typeobject.c's darker corners...
msg24844 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-04-03 13:39
Logged In: YES 
user_id=6656

> This might point to the need for cleaning up typeobject.c's
> darker corners...

No kidding.  Maybe Samuele, you and I can gang up on Guido at 
EuroPython (is he sprinting?  Perhaps we should ask).
msg24845 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2005-12-14 14:57
Logged In: YES 
user_id=4771

The objection to the proposed fix is not valid in light
of the bug #1303614, which gives a general way to abuse
subclassing to allow the __dict__ of an instance to be
assigned to and deleted, even when it should not be allowed.  So I wouldn't worry too much about the case I pointed up, because it should be fixed together with #1303614 (though I don't really know how).  For now I would be happy with just checking that subclassing a non-heap type doesn't move the dict within the structure.

The same remark probably applies to the weakref field.  Both cases could be fixed by being more careful in typeobject.c:extra_ivars(): PyModule_Type should be considered to have extra_ivars() when compared to PyBaseObject_Type.  This could be achieved by skipping the "t_size -= ..." part if "type" is not a heap type.  Indeed, for non-heap types we should not try to consider that an extra dict or weakref slot is not important, because the C code probably accesses this extra slot directly, as in the case of moduleobject.c.
msg24846 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2007-05-02 19:25
Fixed by zseil's patch for #1303614, r55080.
History
Date User Action Args
2022-04-11 14:56:10adminsetgithub: 41786
2005-04-01 09:22:14arigocreate