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.

Title: Pylint recusion stack overflow abort
Type: crash Stage: resolved
Components: Interpreter Core Versions: Python 3.8, Python 3.7, Python 3.6, Python 3.5
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: anthony shaw, cheryl.sabella, eric.smith, jdemeyer, nanjekyejoannah, ncoghlan, nickdrozd
Priority: normal Keywords:

Created on 2018-07-24 20:16 by nickdrozd, last changed 2022-04-11 14:59 by admin. This issue is now closed.

File name Uploaded Description Edit
shell-session nickdrozd, 2018-07-24 20:16
Messages (5)
msg322328 - (view) Author: Nick Drozd (nickdrozd) * Date: 2018-07-24 20:16
In certain very, very specific circumstances, Pylint can cause the interpreter to abort with a stack overflow error.

I've seen this issue on 3.5, 3.6, and 3.8 (I assume it affects 3.7 as well) and on both Mac and Ubuntu.

It requires:
  * 1.7 <= Pylint version < 1.9
  * 1.6.0 <= Astroid version < 1.6.2
    - (For interpreter versions > 3.6, commit is also required.)
  * The dependencies of Pylint and Astroid (I'm not aware of any specific versions needed.)

The crash comes from running Pylint on the file ( This causes the interpreter to abort with the message "Fatal Python error: Cannot recover from stack overflow."

Now, it's not surprising that some kind of stack depth error occurs here, as the target code is recursive, Pylint is recursive, and and Astroid 1.6.0 had a bug in its handling of augmented assign statements (this bug was fixed in 1.6.2 with a one-line change: But this recursion bug should be handled with a RecursionError instead of an abort.

What's strange is that running Pylint on the file (, which differs from in just three characters, does end up with a RecursionError (neither file is large at all). So it looks like something subtle is happening here. I tried looking around to see if I could figure it out, and I could not. All I was able to discover is that changing 50 to other numbers in _Py_CheckRecursiveCall causes the error to come from different places: at the beginning of the eval loop, "while calling a Python object" at several points, and "in comparison".

I've included the text of a shell session showing the errors.

Repo links to versions of Pylint and Astroid that cause the error:

See for further discussion.
msg341335 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2019-05-03 13:11
FYI: this one-liner installs the crashing versions:

pip3 install git+ git+
msg341340 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2019-05-03 14:18
What seems to be happening is a recursion error while handling a recursion error. Essentially

>>> def f():
...     try:
...         f()
...     except:
...         f()
>>> f()
Fatal Python error: Cannot recover from stack overflow.

So unless I'm missing something here, I don't see why this should be considered a CPython bug.
msg341517 - (view) Author: anthony shaw (anthony shaw) Date: 2019-05-06 15:02
I agree with Jerome, that handling recursion errors is a part of a 3rd party package and not a bug with CPython.
msg341521 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python committer) Date: 2019-05-06 15:04
Thank you for the research.  I'm closing this as third party.
Date User Action Args
2022-04-11 14:59:03adminsetgithub: 78395
2019-05-06 15:04:16cheryl.sabellasetstatus: open -> closed

nosy: + cheryl.sabella
messages: + msg341521

resolution: third party
stage: resolved
2019-05-06 15:02:23anthony shawsetnosy: + anthony shaw
messages: + msg341517
2019-05-03 14:18:08jdemeyersetmessages: + msg341340
2019-05-03 13:11:51jdemeyersetnosy: + jdemeyer
messages: + msg341335
2019-04-29 15:05:44nanjekyejoannahsetnosy: + ncoghlan, eric.smith, nanjekyejoannah
2018-07-24 20:16:21nickdrozdcreate