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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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). _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
