STINNER Victor added the comment:
Updated patch for Python 3.4:
- remove PyFrameObject.f_tstate attribute: the thread state can be easily
retrieved, it is known where it is needed (see the patch). There is one
function which doesn't know the thread state: _PyEval_CallTracing(), but this
STINNER Victor added the comment:
ping? (for myself :-))
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14432
___
___
Python-bugs-list mailing
Andrew Suffield asuffi...@suffields.me.uk added the comment:
I think I've tripped over a variation on this theme using pyqt and 2.7:
When working in a QThread, the PyGILState_Ensure call when transitioning
control from Qt to python will frequently allocate a new thread state - because
every
Changes by Antoine Pitrou pit...@free.fr:
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14432
___
___
Python-bugs-list
Mark Shannon m...@hotpy.org added the comment:
Rather than ensuring that f_tstate always points to the current frame,
just remove it altogether.
Patch attached
--
nosy: +Mark.Shannon
Added file: http://bugs.python.org/file25176/remove_f_tstate.patch
Adam Tomjack adam.tomj...@zuerchertech.com added the comment:
For what it's worth, I think I've seen this bug in 2.6 and 2.5, using
generators created in python threads, while profiling not tracing.
I'm creating generators in one python thread and storing them in a variable.
In a different
New submission from STINNER Victor victor.stin...@gmail.com:
We have a crash in our product when tracing is enabled by
sys.settrace() and threading.settrace(). If a Python generator is
created in a C thread, calling the generator later in another thread
may crash if Python tracing is enabled.
Ross Lagerwall rosslagerw...@gmail.com added the comment:
Here's the patch ;-)
--
keywords: +patch
nosy: +rosslagerwall
Added file: http://bugs.python.org/file25055/generator.patch
___
Python tracker rep...@bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
The proposed fix sounds reasonable to me. Would it be possible to work
something into test_capi to actually test it?
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
It may not even have to specifically test the crash - any operation that
accessed the tstate on the frame and could be shown to be accessing the wrong
thread state when called from another thread could demonstrate the problem.
--
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14432
___
___
11 matches
Mail list logo
