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