[issue43923] Can't create generic NamedTuple as of py3.9
Change by Bernie Hackett : -- nosy: +behackett ___ Python tracker <https://bugs.python.org/issue43923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17123] Add OCSP support to ssl module
Bernie Hackett added the comment: OCSP is the only way Let's Encrypt supports revocation. It would be really useful to have stapling verification supported in the standard library, even just the callback support PyOpenSSL supports. https://letsencrypt.org/docs/revoking/ -- nosy: +behackett ___ Python tracker <https://bugs.python.org/issue17123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38890] A subprocess.Popen created with creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning
Change by Bernie Hackett : -- nosy: +behackett ___ Python tracker <https://bugs.python.org/issue38890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow
New submission from Bernie Hackett:
While running PyMongo's test suite against python 3.5.0 the interpreter
inconsistently aborts when we test encoding a recursive data structure like:
evil = {}
evil['evil'] = evil
The test that triggers this was added to test the use of Py_EnterRecursiveCall
in PyMongo's C extensions and passes without issues on all previous CPython
releases back to 2.4.x (the oldest version PyMongo supports). The interesting
thing about this abort is that it only occurs when testing PyMongo *without*
its C extensions. The stacktrace looks like this:
test_bad_encode (test_bson.TestBSON) ... Exception ignored in: >
RecursionError: maximum recursion depth exceeded while calling a Python object
Fatal Python error: Cannot recover from stack overflow.
Thread 0x0b6c (most recent call first):
File "C:\10gen\mongo-python-driver\pymongo\periodic_executor.py", line 105 in
_run
File "C:\Python35\lib\threading.py", line 871 in run
File "C:\Python35\lib\threading.py", line 923 in _bootstrap_inner
File "C:\Python35\lib\threading.py", line 891 in _bootstrap
Thread 0x0690 (most recent call first):
File "C:\Python35\lib\threading.py", line 297 in wait
File "C:\10gen\mongo-python-driver\pymongo\thread_util.py", line 199 in wait
File "C:\10gen\mongo-python-driver\pymongo\periodic_executor.py", line 110 in
_run
File "C:\Python35\lib\threading.py", line 871 in run
File "C:\Python35\lib\threading.py", line 923 in _bootstrap_inner
File "C:\Python35\lib\threading.py", line 891 in _bootstrap
Thread 0x0900 (most recent call first):
File "C:\Python35\lib\threading.py", line 297 in wait
File "C:\10gen\mongo-python-driver\pymongo\thread_util.py", line 199 in wait
File "C:\10gen\mongo-python-driver\pymongo\periodic_executor.py", line 110 in
_run
File "C:\Python35\lib\threading.py", line 871 in run
File "C:\Python35\lib\threading.py", line 923 in _bootstrap_inner
File "C:\Python35\lib\threading.py", line 891 in _bootstrap
Current thread 0x0a20 (most recent call first):
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in
_name_value_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in
_element_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in
_encode_mapping
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in
_name_value_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in
_name_value_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in
_element_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in
_encode_mapping
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in
_name_value_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in
_name_value_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in
_element_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in
_encode_mapping
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in
_name_value_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in
_name_value_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in
_element_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in
_encode_mapping
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in
_name_value_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in
_name_value_to_bson
File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in
_element_to_bson
File &
[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow
Bernie Hackett added the comment: > Well, Python has no perfect protection again stack overflow. It's only best > effect. That's interesting. I thought there was a stronger contract, and it appeared that way in all previous cpython releases back to 2.4. Again, this failure is new with 3.5.0. > You should change sys.setrecursionlimit() to a lower limit to try to limit > the risk of a crash. That's a great suggestion and it appears to work around the issue, thanks. Feel free to close this won't fix, but given that this appears to be the second report of this issue for 3.5 (see issue22971) someone who understands interpreter internals may want to look into the problem a bit more first. -- ___ Python tracker <http://bugs.python.org/issue25222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow
Bernie Hackett added the comment: I used sys.setrecursionlimit(250) - the default appears to be 1000 on all my test machines - and that reduced the occurrence of the abort but didn't completely solve the problem. There must be something more going on here. -- ___ Python tracker <http://bugs.python.org/issue25222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow
Bernie Hackett added the comment: > File > "D:\buildarea\3.4.bolen-windows10\build\lib\test\test_json\test_recursion.py", > line 96 in test_endless_recursion That test (and reason for existence) is almost exactly the same as the PyMongo test that causes abort reported in this ticket. I'm not surprised it is also failing. test_pickle appears to have a similar issue. For test_json see here: https://hg.python.org/cpython/rev/a21f5af476cb And PyMongo's equivalent test: https://github.com/mongodb/mongo-python-driver/blob/4bbe2133a14df716b1dffe8ab7957ed67149b2cd/test/test_bson.py#L538-L543 > I'm unable to reproduce the issue on Linux. The abort is very rare for me on Linux, so much so that I originally thought it only occurred on Windows. I can't reproduce it on a local Linux machine, but it has happened inconsistently in our Jenkins cluster. For example (note that this run includes a commit that uses sys.setrecursionlimit(250) and still aborts): https://jenkins.mongodb.com/view/Python/job/mongo-python-driver/404/extensions=without-extensions,label=linux64,mongodb_configuration=single_server,mongodb_option=noauth,mongodb_server=26-release,python_language_version=3.5/console > First I tried with no MongoDB server running. Then I tried with a MongoDB > server running. The problem only occurs for me when testing with a MongoDB instance running. Running background threads seem to be a key requirement for reproduction. Note also that this problem does not reproduce when using PyMongo's C extensions, only when using the pure python BSON encoder. You can run the tests like this from a clean git checkout: python3.5 setup.py --no_ext test > I don't have exactly the same version (I'm reading pymongo 3.0.3 source) Clone master from github: https://github.com/mongodb/mongo-python-driver > @Bernie: Would you be able to get a C backtrace using gdb on such crash? Not likely, since I can't reproduce it under Linux locally. But I *can* reproduce it consistently on a Windows 7 machine that has VS2015. I'll see what I can get out of the Visual Studio debugger and report back. -- ___ Python tracker <http://bugs.python.org/issue25222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow
Bernie Hackett added the comment: > Clone master from github: You'll also have to git checkout 4bbe2133a14df716b1dffe8ab7957ed67149b2cd to roll back the setrecursionlimit change I added to work around this issue. Using 100 seems to have permanently vanquished the abort, but there's no way the stack is overflowing with such a low setting and Py_EnterRecursiveCall shouldn't cause python to abort all by itself. -- ___ Python tracker <http://bugs.python.org/issue25222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow
Bernie Hackett added the comment: Here's a chunk of the call stack from the Visual Studio debugger using the debug build. Py_FatalError seems to be called multiple times: > ucrtbased.dll!72d27f30()Unknown [Frames below may be incorrect and/or missing, no symbols loaded for ucrtbased.dll] [External Code] python35_d.dll!Py_FatalError(const char * msg) Line 1375C python35_d.dll!_Py_CheckRecursiveCall(const char * where) Line 733 C python35_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2144 C python35_d.dll!call_function_tail(_object * callable, _object * args) Line 2173 C python35_d.dll!callmethod(_object * func, const char * format, char * va, int is_size_t) Line 2242 C python35_d.dll!_PyObject_CallMethodId(_object * o, _Py_Identifier * name, const char * format, ...) Line 2287 C python35_d.dll!flush_std_files() Line 488 C python35_d.dll!Py_FatalError(const char * msg) Line 1354C python35_d.dll!_Py_CheckRecursiveCall(const char * where) Line 733 C python35_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2144 C python35_d.dll!do_call(_object * func, _object * * * pp_stack, int na, int nk) Line 4883C python35_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4679 C python35_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3183 C python35_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4751 C python35_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4677 C python35_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3183 C python35_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4751 C python35_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4677 C python35_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3183 C python35_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 3962C python35_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4760 C -- ___ Python tracker <http://bugs.python.org/issue25222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow
Bernie Hackett added the comment: On second thought, _Py_CheckRecursiveCall may be being called recursively through Py_FatalError. -- ___ Python tracker <http://bugs.python.org/issue25222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24832] Issue building viewable docs with newer sphinx (default theme -> classic)
Bernie Hackett added the comment: We had the same problem with PyMongo's docs. The issue happens with Sphinx 1.3.0 and 1.3.1. It appears to be resolved in 1.3.2. The changelog includes this line (no issue number is mentioned): Add a “default.css” stylesheet (which imports “classic.css”) for compatibility. http://www.sphinx-doc.org/en/stable/changes.html#release-1-3-2-released-nov-29-2015 -- nosy: +behackett ___ Python tracker <http://bugs.python.org/issue24832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
