Description

assignee = None
closed_at = None
created_at = <Date 2021-09-22.19:16:19.650>
labels = ['expert-C-API', 'type-bug', '3.11']
title = 'subtype_clear can not be called from derived types'
updated_at = <Date 2022-01-15.16:35:53.826>
user = 'https://bugs.python.org/VictorMilovanov'

activity = <Date 2022-01-15.16:35:53.826>
actor = 'iritkatriel'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['C API']
creation = <Date 2021-09-22.19:16:19.650>
creator = 'Victor Milovanov'
dependencies = []
files = []
hgrepos = []
issue_num = 45266
keywords = []
message_count = 3.0
messages = ['402466', '402467', '410650']
nosy_count = 2.0
nosy_names = ['Victor Milovanov', 'iritkatriel']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue45266'
versions = ['Python 3.11']

Activity

1. VictorMilovanov commented on Sep 22, 2021

   

   VictorMilovanovmannequin

   on Sep 22, 2021

   MannequinAuthor

   More actions

   I am trying to define a type in C, that derives from PyTypeObject.

   I want to override tp_clear. To do so properly, I should call base type's tp_clear and have it perform its cleanup steps. PyTypeObject has a tp_clear implementation: subtype_clear. Problem is, it assumes the instance it gets is of a type, that does not override PyTypeObject's tp_clear, and behaves incorrectly in 2 ways:

   1. it does not perform the usual cleanup, because in this code
      base = type;
      while ((baseclear = base->tp_clear) == subtype_clear)

   the loop condition is immediately false, as my types overrode tp_clear

   2. later on it calls baseclear on the same object. But because of the loop above baseclear actually points to my type's custom tp_clear implementation, which leads to reentry to that function (basically a stack overflow, unless there's a guard against it).
2. VictorMilovanov

   added

   3.7 (EOL)end of lifeend of life

   3.8 (EOL)end of lifeend of life

   3.9 (EOL)end of lifeend of life

   3.10 (EOL)end of lifeend of life

   3.11only security fixesonly security fixes

   topic-C-API

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Sep 22, 2021
3. VictorMilovanov commented on Sep 22, 2021

   

   VictorMilovanovmannequin

   on Sep 22, 2021

   MannequinAuthor

   More actions

   To put it differently, if you think in terms of MRO, my custom type's MRO is

   my_type_clear (from my type), subtype_clear (from PyTypeObject), etc

   And subtype_clear incorrectly assumes that it is the first entry in the object's MRO list for tp_clear.
4. iritkatriel commented on Jan 15, 2022

   

   iritkatriel

   on Jan 15, 2022

   Member

   More actions

   Victor, it's not clear to me whether this is a bug report or a "how do I do this" question, but in either case if you posted your code along with "I expected X but got Y", it would be easier to understand the issue.
5. iritkatriel

   removed

   3.7 (EOL)end of lifeend of life

   3.8 (EOL)end of lifeend of life

   3.9 (EOL)end of lifeend of life

   3.10 (EOL)end of lifeend of life

   on Jan 15, 2022
6. ezio-melotti

   transferred this issue fromon Apr 10, 2022
7. iritkatriel

   closed this as not plannedon May 13, 2023

Issue actions