Erik Enge writes:
When, in my Zope Python Product, I call a method that does not exist, Zope dies, restarts and then is fine again. If something (another method or a browser perhaps) is calling this method again and again, Zope does a die, restart, rinse, repeat.
I think the problem is that it doesn't throw the necessary Exception, or that it actually throws it, but it is somehow captured by a try-except that I've put out somewhere, so it doesn't show.
Very strange!
Even if the exception was captured, this should not cause Zope to die.
Did you look in the log files? Have their been any core dumps?
Dieter
On Sun, 29 Apr 2001, Erik Enge wrote:
I'll try to do an hour or so of analysing this tomorrow, and I'll get back to you. :-)
Well, now we all know what vikings believe "an hour or so" mean, don't we?
I figured it out, I think. Let's say I have these two methods:
def a(): b()
def b(): a()
If I call a(), then Zope dies and restarts without giving me any error at all. Anyone got a clue? Makes debugging a bit tedious sometimes. I added a couple of print's in the methods and it seem to call them both many times before dying.
I seem to remeber some ExessiveRecursion or some such error that popped up on me a year or two ago, has that left for happier hunting fields?
Erik Enge wrote:
On Sun, 29 Apr 2001, Erik Enge wrote: I figured it out, I think. Let's say I have these two methods:
def a(): b()
def b(): a()
If I call a(), then Zope dies and restarts without giving me any error at all. Anyone got a clue?
There are many places in Zope where errors such as this (RuntimeError - try it in an interactive interpreter) are silently swallowed by too-broad except: clauses (except in this case, the exception is eaten, but the interpreter process exits anyway...).
When we find that our code is dying without notice, we usually try to narrow down the area of code that could be to blame, and then wrap it in our own try/except like:
try: do possibly bad stuff except: import traceback traceback.print_exc() raise
... at least then we know what the exception is.
I seem to remeber some ExessiveRecursion or some such error that popped up on me a year or two ago, has that left for happier hunting fields?
Again - try that code in an interactive interpreter if you really want to find out what's going on...
Richard
Erik Enge wrote:
On Sun, 29 Apr 2001, Erik Enge wrote: I figured it out, I think. Let's say I have these two methods:
def a(): b()
def b(): a()
If I call a(), then Zope dies and restarts without giving me any error at all. Anyone got a clue?
This is an infinite recursion.
I once had such a situation.
Usually Python protects itself against such recursions by limiting the depth of its runtime stack. It raises a "RuntimeError: runtime stack limit exceeded" when its stack overflows.
But in my case, the thread's runtime stack (maintained by the C runtime not Python) was more limited than the Python stack limit. When the thread's stack overflew, the process was killed by Solaris. Python did not have any chance to raise an exception as the death was immediate.
We may need to ask the Python maintainers to increase the thread stack size or to more severely restrict the Python runtime stack.
Dieter
Dieter Maurer wrote:
Erik Enge wrote:
On Sun, 29 Apr 2001, Erik Enge wrote: I figured it out, I think. Let's say I have these two methods:
def a(): b()
def b(): a()
If I call a(), then Zope dies and restarts without giving me any error at all. Anyone got a clue?
This is an infinite recursion.
I once had such a situation.
Usually Python protects itself against such recursions by limiting the depth of its runtime stack. It raises a "RuntimeError: runtime stack limit exceeded" when its stack overflows.
But in my case, the thread's runtime stack (maintained by the C runtime not Python) was more limited than the Python stack limit. When the thread's stack overflew, the process was killed by Solaris. Python did not have any chance to raise an exception as the death was immediate.
We may need to ask the Python maintainers to increase the thread stack size or to more severely restrict the Python runtime stack.
This can be done manually in your site.py - sys.setrecursionlimit()
Richard
On Wed, 6 Jun 2001 richard@bizarsoftware.com.au wrote:
... at least then we know what the exception is.
:
Again - try that code in an interactive interpreter if you really want to find out what's going on...
Yeah, thanks, that would work as a workaround, but isn't this buggish behaviour?
On Wednesday 06 June 2001 18:03, Erik Enge wrote:
On Wed, 6 Jun 2001 richard@bizarsoftware.com.au wrote:
... at least then we know what the exception is.
Again - try that code in an interactive interpreter if you really want to find out what's going on...
Yeah, thanks, that would work as a workaround, but isn't this buggish behaviour?
Absolutely - along with dozens of other places that Zope squashes exceptions. Anthony Baxter actually wrote a script that finds instances of bare except: clauses in the Zope source...
http://www.zope.org/Members/anthony/BarewordExcepts
Feel free to find the bad except: and submit a patch...
Richard
-
Dieter Maurer -
Erik Enge -
Richard Jones -
richard＠bizarsoftware.com.au