Repository navigation
[BUG] Cython/Utility/Profile.c use of use_tracing broken by recent Python 3.10 change #4153
Description
Describe the bug
Cython/Utility/Profile.c uses tstate->use_tracing but a recent change in the upcoming Python 3.10 has moved this field down to a new tstate->cframe->use_tracing location, leading to Profile.c failing to compile. See python/cpython#25276 and bpo-43760.
To Reproduce
Code to reproduce the behaviour:
N.A. (essentially any, if # cython: profile=True or linetrace=True is activated)
Expected behavior
Cython-using code compiles successfully.
Environment (please complete the following information):
- OS: observed on Linux
- Python version: 3.10
- Cython version: problem present in master
Additional context
Reported on a Cython-using project as pysam-developers/pysam#1015.
Activity
jmarshall commentedon May 11, 2021
bpo-43760 is freshly active and has suggested the possibility of introducing accessor functions, but is mostly at the stage of finding out what the reasons are for code outwith CPython wanting to directly access
use_tracing.Workaround for missing tstate->use_tracing in Python 3.10
hroncok commentedon May 19, 2021
I'm attempting to get a working solution (even if temporary) in #4173
scoder commentedon May 19, 2021
This is already resolved for master in
c9cccfe
78f1ca8
hroncok commentedon May 19, 2021
Should I attempt a backport instead then?
scoder commentedon May 19, 2021
The change applies cleanly to 0.29.x as well. I'll push it there. Sorry for the duplicate effort.
pablogsal commentedon Sep 23, 2021
This may be dangerous for two reasons:
tstate->use_tracinghad global effect before, whiletstate->cframe->use_tracingonly affects the last executing frame. Modifiying this value only affects that particular frame. The semantics are different.tstate->cframepoints to a stack allocated variable in ceval. Accessing this from heap objects may be dangerous.