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.

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?
History
Date User Action Args
2012-04-16 14:13:58asuffieldsetrecipients: + asuffield, ncoghlan, pitrou, vstinner, asvetlov, adamtj, neologix, Mark.Shannon, rosslagerwall
2012-04-16 14:13:57asuffieldsetmessageid: <1334585637.93.0.985530722738.issue14432@psf.upfronthosting.co.za>
2012-04-16 14:13:57asuffieldlinkissue14432 messages
2012-04-16 14:13:57asuffieldcreate