[Mono-bugs] [Bug 75014][Nor] Changed - Using RAIL to copy a method with exception handlers triggers assertion

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Sat May 21 05:30:12 EDT 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 vladimir at pobox.com.

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

--- shadow/75014	2005-05-20 22:13:50.000000000 -0400
+++ shadow/75014.tmp.23421	2005-05-21 05:30:12.000000000 -0400
@@ -57,6 +57,25 @@
 Write: 0 EndExceptionBlock
 Handler 0 at 0, len: 0
 
 it then blows up there, because ILExceptionInfo.Debug() gets a null
 reference exception when trying to dump the handler info.  (The Write
 bits are coming from dumps I put into RAIL's Instruction.cs)
+
+------- Additional Comments From vladimir at pobox.com  2005-05-21 05:30 -------
+
+Hmm.. if I compile foo.cs into foo.dll using CSC, and then move to
+mono, I can run the RAIL bits fine.  Taking the mcs/mono-built .dll to
+.NET results in System.InvalidOperationException: Incorrect code
+generation for exception block.
+
+disassembly shows mono/mcs inserting a try { } finally { } around the
+entire function body, but the leave instruction at the end of the
+inner try {} and catch {} point to the end of the function, outside of
+the outermost try {} finally {}.  If a try { } finally { } is manually
+placed around the function body, both mcs and csc generate jump to an
+intermediate point at the end of the outer try, which is itself a
+leave instruction to after the finally.  (Boy, that's confusing..
+easier to take a look at the disassembly to see what I mean.)
+
+So, this may be a mcs bug and not a runtime bug...
+


More information about the mono-bugs mailing list