---- Reported by jeroen@sumatra.nl 2006-10-09 03:15:28 MST ----

C:\j\mono-cust-bug>mono test.exe

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

Stacktrace:

  at (wrapper managed-to-native) 
System.MonoCustomAttrs.GetCustomAttributesInternal 
(System.Reflection.ICustomAttributeProvider,System.Type,bool) <0x00004>
  at (wrapper managed-to-native) 
System.MonoCustomAttrs.GetCustomAttributesInternal 
(System.Reflection.ICustomAttributeProvider,System.Type,bool) <0xffffffff>
  at System.MonoCustomAttrs.GetCustomAttributesBase 
(System.Reflection.ICustomAttributeProvider,System.Type) <0x00025>
  at System.MonoCustomAttrs.GetCustomAttributes 
(System.Reflection.ICustomAttributeProvider,System.Type,bool) <0x0007e>
  at System.Reflection.Module.GetCustomAttributes (System.Type,bool) 
<0x00012>
  at IKVM.Internal.AssemblyClassLoader..ctor 
(System.Reflection.Assembly,object) <0x0008c>
  at IKVM.Internal.ClassLoaderWrapper.GetAssemblyClassLoader 
(System.Reflection.Assembly) <0x0009e>
  at IKVM.NativeCode.gnu.classpath.VMStackWalker.getClassLoaderFromType 
(System.Type) <0x0006a>
  at gnu.classpath.VMStackWalker.getClassLoaderFromType (System.Type) 
<0x0000a>
  at gnu.classpath.VMStackWalker.getCallingClassLoader () <0x000a0>
  at java.lang.Package.getPackages () <0x0000b>
  at test.Main () <0x0000e>
  at (wrapper runtime-invoke) System.Object.runtime_invoke_void 
(object,intptr,intptr,intptr) <0xffffffff>

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.



---- Additional Comments From jeroen@sumatra.nl 2006-10-09 03:31:22 MST ----

It looks like the repro is too big for an attachment. So I've made 
it available here: http://www.frijters.net/mono-bug-79626.zip



---- Additional Comments From vargaz@gmail.com 2006-10-09 08:01:46 MST ----

The crash is easy to fix but the test.exe file seems a bit strange, i.e.
its FILE table contains two entries referencing the two .netmodules,
but the MODULEREF table doesn't contain any entries. 



---- Additional Comments From jeroen@sumatra.nl 2006-10-09 08:06:25 MST ----

Interesting. test.exe was created with Microsoft's C# compiler (.NET 
1.1) and peverify doesn't complain about it, so if it's not too 
difficult it's probably a good idea to support this.



---- Additional Comments From jeroen@sumatra.nl 2006-10-09 12:44:53 MST ----

I've given it some more thought and I think that csc is actually 
correct. Since test.exe does not reference any types in the modules, 
it makes sense that the moduleref table is empty.



---- Additional Comments From vargaz@gmail.com 2006-10-09 15:17:31 MST ----

IMHO, Assembly.GetModules () shouldn't return the entries in the Files
table. But we will need to implement this for compatibility anyway.





---- Additional Comments From jeroen@sumatra.nl 2006-10-09 17:24:17 MST ----

I'm no metadata expert, but I think you're mistaken. Take a look at 
Assembly.GetModules(bool). The resource modules it mentions are 
simply binary files (not PE files) and hence a module is simply a 
file which may or may not be a PE file. This strongly implies that 
the File table is used and not the ModuleRef table.



Unknown operating system unknown. Setting to default OS "Other".