Christian Heimes added the comment:
I can no longer reproduce the crash with:
>>> def func(): pass
...
>>> call = func.__call__
>>> while True:
... call = call.__call__
Tested with 2.7, 3.5 and 3.6dev.
--
nosy: +christian.heimes
resolution: -> works for me
status: open ->
Alex alex.gay...@gmail.com added the comment:
I doubt there is a good usecase for it, nevertheless we should attempt to fix
it, as segfaults are no good.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9743
Éric Araujo mer...@netwok.org added the comment:
“Recursively getting __call__ method from existing __call__”
I wonder what is the use case for this.
--
nosy: +eric.araujo
versions: -Python 2.6
___
Python tracker rep...@bugs.python.org
New submission from Lily 2ch.ow...@gmail.com:
Recursively getting __call__ method from existing __call__ causes interpreter
infinitely grow in memory and calling resulting
__call__.__call__...__call__.__call__() chain results in crash.
Platform: Windows 7 (x64)
Version: Python 2.7 (r27:82525)
Eric Smith e...@trueblade.com added the comment:
I can duplicate this as a segmentation fault under 2.7 on Mac OS, but not under
Windows 2.6 (ActiveState).
What platform are you using, and what output do you see?
--
nosy: +eric.smith
___
Python
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
On Windows, a stack overflow often causes the program to silently exit.
Try to add some print statement at the end and see if it executes.
--
nosy: +amaury.forgeotdarc
___
Python tracker
Alex alex.gay...@gmail.com added the comment:
This seems to be another case of C stack depth not reflected in the stack
counter.
--
nosy: +alex
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9743
Eric Smith e...@trueblade.com added the comment:
Amaury: Good point. The Windows version is failing, too. A print statement at
the end doesn't get executed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9743
