Message158455
| Author |
asuffield |
| Recipients |
Mark.Shannon, adamtj, asuffield, asvetlov, ncoghlan, neologix, pitrou, rosslagerwall, vstinner |
| Date |
2012年04月16日.14:13:57 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1334585637.93.0.985530722738.issue14432@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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 time control returns to the Qt event loop, gilstate_counter is likely to become zero.
If a generator is kept around longer than this, it becomes quite likely to have an older thread state in f_tstate. This happens all the time.
The access that blows up on me is PyEval_GetRestricted, since PyFrame_IsRestricted checks f_tstate. Annoyingly this debris is still called on the possibly-restricted operations even when restricted execution is nowhere in sight.
Hence, any use of open() in a long-lived generator in a QThread is probably going to crash.
Patch against 2.7? |
|