Serhiy Storchaka added the comment:
> The json code was almost not changed, so it can be related to changes in import machinery or in ceval.c if they consume more stack than previous.
>
> Yet one suspect is Argument Clinic that adds additional wrappers.

This issue is about the number of Python frames, right? Argument Clinic may use a little bit more bytes on the C stack, but it doesn't create Python frames. Right?

--

Current thread 0x00000a20 (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 <listcomp>
  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
  ...

The "Fatal Python error: Cannot recover from stack overflow" occurs when Python already raised a RecursionError (RuntimeError on Python < 3.5) in the current Python thread, but the recursion limit was reached again, even with 50 more frames than when the RecursionError was raised.

Since a RecursionError exception was raised, I would expect the program to crash in an except block, but it's not the case.

_name_value_to_bson:653: I don't have exactly the same version (I'm reading pymongo 3.0.3 source), but I only see a try/except KeyError here. No bare "except: pass" or "except Exception: ...".

_element_to_bson:692: Ditto, only a try/except AttributeError.

--

@Bernie: Would you be able to get a C backtrace using gdb on such crash?