[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