Bugzilla – Bug 317804
[PATCH] mono not able to handle typeref to a nested class in the same assembly
Last modified: 2007-09-15 21:24:46 UTC
---- Reported by radical@gmail.com 2005-04-26 06:52:13 MST ---- Attached is a test case and the patch. ilasm'ing the test-case on .net and trying to run under mono gives: $ mono n.exe ** ERROR **: pending init .abc aborting... Aborted $ monodis n.exe .assembly extern mscorlib { .ver 1:0:5000:0 .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4.. } .assembly 'n' { .hash algorithm 0x00008004 .ver 0:0:0:0 } .module n.exe // GUID = {BCFB3BB1-33A0-402B-A81D-B0CE2B07417C} .class public auto ansi beforefieldinit abc extends [mscorlib]System.Object { ** ERROR **: pending init .abc aborting... Aborted ----------------------------------------------- Basically, .net is emitting a TypeRef for a nested type which is referenced before it is defined, even though it is in the same assembly. This is valid so it should be handled by mono. The same .il compiled with our ilasm emits the correct TypeDef. ---- Additional Comments From radical@gmail.com 2005-04-26 06:53:10 MST ---- Created an attachment (id=167808) Patch ---- Additional Comments From radical@gmail.com 2005-04-26 06:53:41 MST ---- Created an attachment (id=167809) Test case: n.il ---- Additional Comments From radical@gmail.com 2005-04-26 06:57:51 MST ---- Oops, forgot : Patch is by Hari. ---- Additional Comments From miguel@ximian.com 2005-04-26 16:42:58 MST ---- CCing Paolo and Zoltan. ---- Additional Comments From vargaz@gmail.com 2005-04-28 07:14:32 MST ---- Could you attach the generated .exe file as well, since the 2.0 ilasm seem to generate a TypeDef in this case. ---- Additional Comments From radical@gmail.com 2005-04-28 09:53:23 MST ---- Created an attachment (id=167810) n2.exe : Compiled with ilasm.exe Version 1.1.4322.2032 (.net) ---- Additional Comments From vargaz@gmail.com 2005-04-28 12:00:39 MST ---- Fixed in SVN. Thanks for the patch. ---- Additional Comments From rharinath@novell.com 2005-04-29 00:21:45 MST ---- I missed mono_loader_unlock in there. On that topic, is the lock recursive? Here, we have mono_class_init invoked recursively -- why didn't it deadlock? Imported an attachment (id=167808) Imported an attachment (id=167809) Imported an attachment (id=167810) Unknown operating system unknown. Setting to default OS "Other".