[Mono-bugs] [Bug 81685][Wis] Changed - Stack Overflow detection

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by lupus at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=81685

--- shadow/81685	2007-05-24 11:48:31.000000000 -0400
+++ shadow/81685.tmp.6499	2007-05-24 14:19:55.000000000 -0400
@@ -167,6 +167,36 @@
 We were talking specifically about managed code not about interactions
 with unmanaged code (which would make things even worse).
 
 One of the points is finalizers: there is no way you can guarantee
 proper unwinding if the finalizers can potentially cause another stack
 overflow (as Robert example shows).
+
+------- Additional Comments From lupus at ximian.com  2007-05-24 14:19 -------
+Finalizers are not involved in robert's sample, finally clauses are.
+As I wrote above, finally clauses overflowing can be handled, it all
+depends on how many pages we want to reserve. You need to consider two
+things: runtime stability and application stability. What matters is
+runtime stability, if an app misbehaves it's correct to see it die,
+what matters is that it must not take down the runtime with it.
+
+Now an app may cause a stack overflow, we extend the stack a few pages
+to handle it and start executing the finally clauses. There are two
+cases: finally clauses that involve runtime data structures and
+possibly-malicious app finally clauses. The runtime-relevant finally
+clauses must be well behaved or we have a bug in the runtime, so they
+can't overrflow again (of course we need to tune the number of trigger
+pages at the end of the stack according to our runtime needs, hence my
+remarks above about using less stack in the runtime). Since the
+runtime finally clauses are well behaved they execute and there is no
+corruption of runtime data structures (say, a finally clause needs to
+run to unlock a monitor).
+
+App-finally clauses can cause a new overflow, in this case we just
+make the finally clause quit and possibly the thread/app die, but this
+doesn't involve the runtime reliability, only that app (which may not
+be the only one running inside the runtime, hence the importance of
+killing just the app and not the system).
+
+So either Jim was wrong or there was a misunderstanding (or there is a
+security advisory out there with a trivial program to crash both the
+CLR and any JVM, since they need to deal with this same issue).