Bug - Fixed Stack overflow in script execution breaks gCLI

[heeheehee]

With poorly written scripts (by me, of course!), if a stack overflow occurs, then the script halts as soon as the stack overflow occurs, but no more input can be given to the CLI. No amount of aborting seems to help. On the other hand, I can visit relay pages with overrides (and can keep on doing so even if there's a stack overflow triggered there).

Sample code for reproducing:

> ash void func() {func();} func();

 

[fronobulax]

Don't do that. Seriously. As a general rule the instant the stack overflow occurs the only safe user action is to shut down mafia and restart. Any attempt to continue would be entirely at your own risk.

That said, if the issue is that you can write something that generates a stack overflow rather than some kind of error message then there might be something that could be done.

 

[Veracity]

Don't do that. Seriously. As a general rule the instant the stack overflow occurs the only safe user action is to shut down mafia and restart. Any attempt to continue would be entirely at your own risk.

Why? I agree with this for running out of heap space, but for a Stack Overflow, Java just rolls back the stack, unwinding through try/catch/finally frames, to wherever you catch it.

If the issue is that you can write something that generates a stack overflow rather than some kind of error message then there might be something that could be done.

What? Disable recursion in ASH? Analyze the program and ... somehow ... determine that it is recursive but a recursion-breaking condition cannot happen? That's complicated.

I think we could trap a StackOverFlowException in Interpreter.execute. We don't need a stack trace for that, probably, since it won't help you tell which function is recuring.

In fact, we currently trap other exceptions and print a stack trace - but leave the display disabled - which is what the bug report is complaining about.

 

[Veracity]

Revision 9639.

 

[heeheehee]

Thanks, Veracity.