[Python-Dev] Preventing recursion core dumps (original) (raw)

Barry Scott barry@scottb.demon.co.uk
Fri, 11 Aug 2000 12:42:11 +0100

Why not set a limit in the intepreter? Fixing this for every call in object.c seems a lots of hard work and will always leave holes.

For embedding Python being able to control the recursion depth of the intepreter is very useful. I would want to be able to set, from C, the max call depth limit and the current call depth limit. I'd expect Python to set a min call depth limit.

    BArry

-----Original Message----- From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On Behalf Of Vladimir Marangozov Sent: 11 August 2000 03:00 To: Python core developers Subject: [Python-Dev] Preventing recursion core dumps

I'm looking at preventing core dumps due to recursive calls. With simple nested call counters for every function in object.c, limited to 500 levels deep recursions, I think this works okay for repr, str and print. It solves most of the complaints, like: class Crasher: def str(self): print self print Crasher() With such protection, instead of a core dump, we'll get an exception: RuntimeError: Recursion too deep So far, so good. 500 nested calls to repr, str or print are likely to be programming bugs. Now I wonder whether it's a good idea to do the same thing for getattr and setattr, to avoid crashes like: class Crasher: def getattr(self, x): return self.x Crasher().bonk Solving this the same way is likely to slow things down a bit, but would prevent the crash. OTOH, in a complex object hierarchy with tons of delegation and/or lookup dispatching, 500 nested calls is probably not enough. Or am I wondering too much? Opinions? -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

Python-Dev mailing list Python-Dev@python.org http://www.python.org/mailman/listinfo/python-dev