| msg71478 - (view) |
Author: Roger Upole (rupole) |
Date: 2008-08-19 20:42 |
| Py_FatalError calls PyErr_Occurred() which requires a current thread state. This mean that if the original error was a thread state error Py_FatalError is triggered again, ad infinitum. |
|
|
| msg71485 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-08-19 21:08 |
| Do you have a simple code sample to showcase that? |
|
|
| msg71487 - (view) |
Author: Roger Upole (rupole) |
Date: 2008-08-19 21:28 |
| Py_BEGIN_ALLOW_THREADS PyErr_SetString(PyExc_SystemError, "bork bork bork"); Py_END_ALLOW_THREADS |
|
|
| msg71488 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2008-08-19 21:30 |
| > Roger Upole <rupole@hotmail.com> added the comment: > > Py_BEGIN_ALLOW_THREADS > PyErr_SetString(PyExc_SystemError, "bork bork bork"); > Py_END_ALLOW_THREADS Well, if you start using all kinds of internal APIs without holding the GIL, you should expect much worse than just a Py_FatalError ;-) Of course, it would still be better if the infinite loop could be avoided. |
|
|
| msg71489 - (view) |
Author: Roger Upole (rupole) |
Date: 2008-08-19 21:43 |
| Well, you asked for a simple case. In practice, I'm dealing with much more complicated code that contains callbacks which may need to acquire or release the theadlock. This problem makes it very difficult to debug such code. Also, the PyErr_Occurred is not present in 2.5.2, probably for this very same reason. |
|
|
| msg105612 - (view) |
Author: Jeffrey Yasskin (jyasskin) * |
Date: 2010-05-12 23:36 |
| I have a fix at http://codereview.appspot.com/1184043, which makes PyErr_Occurred() return NULL when there is no thread. I'll commit it tomorrow unless there are comments. |
|
|
| msg105650 - (view) |
Author: Jeffrey Yasskin (jyasskin) * |
Date: 2010-05-13 18:31 |
| Fixed in r81142. |
|
|
| msg105781 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2010-05-15 01:43 |
| I fixed the new test for Windows: r81183 (py3k). The new test failed on Windows because of the different newline characters: Traceback (most recent call last): File "...\test_capi.py", line 49, in test_no_FatalError_infinite_loop b'Fatal Python error:' AssertionError: b'Fatal Python error: PyThreadState_Get: no current thread\r\n' != b'Fatal Python error: PyThreadState_Get: no current thread\n' |
|
|
| msg120302 - (view) |
Author: Roger Upole (rupole) |
Date: 2010-11-03 02:32 |
| I know this has been closed, but I disagree with the fix. Py_FatalError is designed to give a clean exit with a readable error message when the state of the interpreter is known to be compromised. Calling *any* python functions or accessing *any* python internals is only likely to lead to more issues that obscure the original problems. IMO the PyErr_Occurred needs to be removed entirely. |
|
|
| msg141289 - (view) |
Author: Neil Aspinall (mocmocamoc) * |
Date: 2011-07-28 10:58 |
| Would it be possible for this issue's fix (PyErr_Occurred() returning null when the thread state is null) to be applied to the 2.7 branch? |
|
|
| msg356185 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2019-11-07 11:42 |
| New changeset d12d0e7c0fe2b49c40ac4d66365147c619d6c475 by Victor Stinner in branch 'master': bpo-38733: PyErr_Occurred() caller must hold the GIL (GH-17080) https://github.com/python/cpython/commit/d12d0e7c0fe2b49c40ac4d66365147c619d6c475 |
|
|