The following code will obviously cause a memory leak, but this will not be detected and crash the interpreter:

    def inf():
      while True: yield 0

    def use(*parm):
      for i in parm: print(i)

and then

    use(*inf())

or 

    print(*int())

The reason of this test is that I wanted to check if ever python would be able to make lazy evaluation in parameter passing (It would be nice if it was but it is not the case). However, at least, I think this error should have been detected as well as an infinite recursion is, because it even has been able to crash and reboot a not so old (18) version of linux Mint.

On Windows, I get an indefinite hang rather than an overt crash with a crash box.  I believe that there was some swapping out to disk.  I got the same with list(itertools.count()). 

If you got a core dump or crash report, you might upload it.  

There is infinite looping in the argument collection but no infinite recursion (calling) here.  The latter is detected pretty quickly because of sys.recursion limit.  Infinite loops by themselves are not necessarily wrong.  This typing box is run by an infinite loop.  Change your 'use' to

def use(iter):
    for i in iter: print(i)

and there would be no problem.  So I disagree with 'should have been detected'.  I am only leaving this open in case you got an overt crash for this particular loop.  Those we try to fix.

Well, I know an infinite loop  is not necessarily wrong, especially in a generator. and I also know how to avoid this problem.
My problem is not there. It's just that I believe it should possibly crash the program and not the interpreter. 
I even wonder if being able to cause an interpreter crash couldn't become a security hole in some cases.probably the basic solution would be to forward an exception to the program if the interpreter running it gets an allocation error.

About core dump or crash report, it didn't generate one but I think I should install a few things on the computer to get it.

    Le dimanche 30 août 2020 à 02:02:01 UTC+2, Terry J. Reedy <report@bugs.python.org> a écrit :  

Terry J. Reedy <tjreedy@udel.edu> added the comment:

On Windows, I get an indefinite hang rather than an overt crash with a crash box.  I believe that there was some swapping out to disk.  I got the same with list(itertools.count()). 

If you got a core dump or crash report, you might upload it.  

There is infinite looping in the argument collection but no infinite recursion (calling) here.  The latter is detected pretty quickly because of sys.recursion limit.  Infinite loops by themselves are not necessarily wrong.  This typing box is run by an infinite loop.  Change your 'use' to

def use(iter):
    for i in iter: print(i)

and there would be no problem.  So I disagree with 'should have been detected'.  I am only leaving this open in case you got an overt crash for this particular loop.  Those we try to fix.

----------
nosy: +terry.reedy
title: Calling a function with an infinite number of parameters is not detected and crash the interpreter instead of causing an exception -> Calling with an infinite number of parameters is not detected
versions: +Python 3.9

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue41637>
_______________________________________

It does not differ much from list(inf()). Sooner or later it will raise MemoryError. You can interrupt the execution by pressing Ctrl-C. Although the response may be slow if your computer started swapping.

There is nothing special about unpacking infinite number of parameters. You can achieve the same result in many other ways in any programming language. If you want you program do not use too much swap, limit the virtual memory size by the shell ulimit command (or by resource.setrlimit() in Python).

I understand all that. But the problem is that it should crash the program and not the interpreter.