Dear Friends,
It seems that I manage to find a problem with Python ... version 3.6.3
Attached is a PY file designed to solve a puzzle: see function makeGame1

To find a solution run: doFind() 
>>> doFind()

----> counter: 11735841 rec depth: 2367
86792-719
72581-938
916-398--
--9378-97
3985-4859
27-2879--
--819-698
937-69782
812-78561
----> counter: 29203691
>>> 

It takes a few seconds to come up with a solution (deep recursive exhaustive search)
if you switch between lines 109 <==> 110 then it restart Python !?!?!?!?! (see below)

>>> doFind()

=============================== RESTART: Shell ===============================
>>> 

Dr. Shimon Cohen 
shamon51@gmail.com

lines 209 <==> 210

Can you reproduce this with a much smaller example?

Not really...
Did you see the "restart" ?

On Nov 14, 2017 2:38 PM, "Eric V. Smith" <report@bugs.python.org> wrote:

>
> Eric V. Smith <eric@trueblade.com> added the comment:
>
> Can you reproduce this with a much smaller example?
>
> ----------
> nosy: +eric.smith
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue32022>
> _______________________________________
>

That's too much code for me to run without analyzing it first. If I have time, I'll look at it.

Here is another simple example - Simple? the game board ==> is small 
see attached PY file
run ==> doFind()

The RESTART line means that you ran this in IDLE and that your program crashed the separate (sub)process that was running your code.  When IDLE notices this, it starts a new subprocess.

To test whether this is an IDLE-only problem, I ran your code without IDLE.

C:\Users\Terry>python -i -m tem
>>> doFind()
R 6 12
R 12 22
R 21 32
C 10 21
C 13 22
C 16 23

and quickly got the the Windows 'Program has stopped running' box, with no Python error message.  Ditto when run on 3.7.0a2.

Since this is not an IDLE issue, I revised the title.

It is possible that this is a duplicate of an existing crash report, but I am not familiar with such at all.  With only the standard, non-specific  error message, it is hard to search ;-).  What OS are you using?

I believe I used the 2nd version of kakuru.py.

Cool, thanks!

On Nov 18, 2017 5:29 AM, "Terry J. Reedy" <report@bugs.python.org> wrote:

>
> Terry J. Reedy <tjreedy@udel.edu> added the comment:
>
> I believe I used the 2nd version of kakuru.py.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue32022>
> _______________________________________
>

PS.  When you respond by EMail, please delete the quoted message, as it is redundant, on the web page, with the original copy above.

On linux x86-64 with python 3.6.3 and python 3.7.0a2+ I get a RecursionError: maximum recursion depth exceeded.

I don't think that we can fix this issue. I suggest to close it as WONTFIX.


> sys.setrecursionlimit(3000)

While Python does its best to catch stack overflow, the C implementation of CPython can exhaust the stack memory (8 MB in Linux?) and then crash with a "stack overflow".

I suggest to rewrite your algorithm to reduce the maximum stack depth.

Or maybe try to find a way to extend the maximum size of the stack (is it possible without rebuilding Python?). See for example RLIMIT_STACK of the resource module on Unix.


> On linux x86-64 with python 3.6.3 and python 3.7.0a2+ I get a RecursionError: maximum recursion depth exceeded.

The exact memory usage depends on the Python version and maybe compiler flags. We reduce the stack usage in Python 3.7, search for "Stack consumption" in:

https://vstinner.github.io/contrib-cpython-2017q1.html

> I suggest to close it as WONTFIX.

Agreed. If you use sys.setrecursionlimit, you're deliberately bypassing Python's safety mechanisms. A crash due to stack overflow shouldn't be considered a bug under these circumstances.

I was going to suggest that this might be a documentation issue, but the existing documentation already looks sufficient to me:

> A user may need to set the limit higher when they have a program that
> requires deep recursion and a platform that supports a higher limit.
> This should be done with care, because a too-high limit can lead to a
> crash.

From https://docs.python.org/3/library/sys.html#sys.setrecursionlimit

I close the issue for the reasons given in the latest comments. Sorry!

(Oops, must be closed as "wont fix".)

I confirmed that increasing the recursion limit can change recursion behavior on Windows.

>>> def f(): g()
...
>>> def g(): f()
...
>>> f()

With the default limit or 1000 or increase to 3000, I get a recursion error.  With the limit set to 10000, I get 'MemoryError: stack overflow'.  It is not too surprising that the more complicated code prevents getting even that.