[Mono-bugs] [Bug 76996][Nor] Changed - Inconsistent behaviour on PPC when throwing an exception in a finally block

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Wed Dec 28 14:38:39 EST 2005


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 vargaz at gmail.com.

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

--- shadow/76996	2005-12-20 10:26:16.000000000 -0500
+++ shadow/76996.tmp.6289	2005-12-28 14:38:38.000000000 -0500
@@ -81,6 +81,43 @@
 ------- Additional Comments From robertj at gmx.net  2005-12-14 16:21 -------
 "foo" cannot be reported, because the outer catch block
 never sees this exception. This is by design.
 
 Removed "x86" from the subject and changed the prio to "normal".
 
+
+------- Additional Comments From vargaz at gmail.com  2005-12-28 14:38 -------
+I think this is similar to:
+
+http://bugzilla.ximian.com/show_bug.cgi?id=76388
+
+The problem is that the finally clauses are called by the exception
+handling code through a trampoline, so when an exception is thrown 
+from the finally clause, the stack contains frames for the call_finally
+trampoline, mono_handle_exception () etc. The exception handling code
+doesn't have unwind info for these, and there is no LMF between the
+trampoline and the finally handler, so it is converted to an unhandled
+exception. Another problem is this code:
+
+   try {
+        try {
+            throw new Exception ();
+        }
+        finally {
+            throw new Exception ();
+        }
+   }
+   catch (Exception ex) {
+      return ...
+   }
+
+When the exception is thrown from the finally clause, it is caught by
+the outer catch handler which returns from the method, but the caller
+of this frame is not a normal method, but the call_finally trampoline,
+which uses an entirely different calling convention to call the
+finally code, so for example, if the method returns a structure, the
+register/stack slot holding the vtype pointer might not be set, or if
+the caller needs to do stack cleanup, the finally trampoline does not
+do it. etc.
+
+
+


More information about the mono-bugs mailing list