[Mono-bugs] [Bug 421744] New: SIGSEGV using Type.IsAssignableFrom with MonoGenericClass

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Sat Aug 30 13:21:12 EDT 2008


           Summary: SIGSEGV using Type.IsAssignableFrom with
           Product: Mono: Runtime
           Version: 2.0
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: generics
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: gert.driesen at pandora.be
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---

Using Type.IsAssignableFrom to check whether a given type is assignable from a
dynamically constructed generic type (MonoGenericClass) results in a SIGSEGV.

On MS, Type.IsAssignable apparently always returns false when dynamically
constructed generic type (called TypeBuilderInstantiation on MS) is passed as

To reproduce, compile and run the following code:

using System;
using System.Reflection;
using System.Reflection.Emit;

class Program
        static void Main ()
                AssemblyName assemblyName = new AssemblyName ();
                assemblyName.Name = "Lib";

                AssemblyBuilder assembly =
AppDomain.CurrentDomain.DefineDynamicAssembly (
                        assemblyName, AssemblyBuilderAccess.RunAndSave,

                ModuleBuilder module = assembly.DefineDynamicModule ("Lib");

                TypeBuilder tb = module.DefineType ("Foo",
                        null, new Type [] { typeof (IBar) });
                tb.DefineGenericParameters ("T");

                Type typeBarOfInt32 = tb.MakeGenericType (typeof (int));

                Console.WriteLine (typeBarOfInt32.GetType ().ToString ());
                Console.WriteLine (typeof (IComparable).IsAssignableFrom
                Console.WriteLine (typeof (IBar).IsAssignableFrom

public interface IBar

Expected result:


Actual result:


  at (wrapper managed-to-native) System.Type.type_is_assignable_from
(System.Type,System.Type) <0x00004>
  at (wrapper managed-to-native) System.Type.type_is_assignable_from
(System.Type,System.Type) <0xffffffff>
  at System.Type.IsAssignableFrom (System.Type) <0x00103>
  at Program.Main () <0x00162>
  at (wrapper runtime-invoke) object.runtime_invoke_void
(object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

        mono [0x806fbc9]
        mono [0x808a391]
        mono(mono_runtime_exec_main+0xeb) [0x80b11eb]
        mono(mono_runtime_run_main+0x173) [0x80b2723]
        mono(mono_main+0x13db) [0x805c76b]
        mono [0x805adf2]
        /lib/libc.so.6(__libc_start_main+0xe0) [0xb7cfefe0]
        mono [0x805ad61]

Debug info from gdb:

[?1034hUsing host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 0xb7ce8b80 (LWP 6755)]
[New Thread 0xb753bb90 (LWP 6757)]
[New Thread 0xb755fb90 (LWP 6756)]
0xffffe410 in __kernel_vsyscall ()
  3 Thread 0xb755fb90 (LWP 6756)  0xffffe410 in __kernel_vsyscall ()
  2 Thread 0xb753bb90 (LWP 6757)  0xffffe410 in __kernel_vsyscall ()
  1 Thread 0xb7ce8b80 (LWP 6755)  0xffffe410 in __kernel_vsyscall ()

Thread 3 (Thread 0xb755fb90 (LWP 6756)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e4d846 in nanosleep () from /lib/libpthread.so.0
#2  0x0815f231 in collection_thread (unused=0x0) at collection.c:34
#3  0xb7e46192 in start_thread () from /lib/libpthread.so.0
#4  0xb7dac02e in clone () from /lib/libc.so.6

Thread 2 (Thread 0xb753bb90 (LWP 6757)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e4a566 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so0
#2  0x0814acef in timedwait_signal_poll_cond (cond=0x831a15c, mutex=0x831a144, 
    timeout=0x0, alertable=0) at handles.c:1490
#3  0x0814d9be in _wapi_handle_timedwait_signal_handle (handle=0x404, 
    timeout=0x0, alertable=0) at handles.c:1570
#4  0x0814da3c in _wapi_handle_wait_signal_handle (handle=0x404, alertable=0)
    at handles.c:1530
#5  0x08152d2a in WaitForSingleObjectEx (handle=0x404, timeout=4294967295, 
    alertable=0) at wait.c:205
#6  0x080c14ca in finalizer_thread (unused=0x0) at gc.c:905
#7  0x08129c30 in start_wrapper (data=0x83177c8) at threads.c:621
#8  0x08161082 in thread_start_routine (args=0x831a39c) at threads.c:279
#9  0x081784a5 in GC_start_routine (arg=0x26f20) at pthread_support.c:1382
#10 0xb7e46192 in start_thread () from /lib/libpthread.so.0
#11 0xb7dac02e in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb7ce8b80 (LWP 6755)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e4cffb in read () from /lib/libpthread.so.0
#2  0x0806fcc3 in mono_handle_native_sigsegv (signal=11, ctx=0xb7bb7d0c)
    at mini-exceptions.c:1324
#3  0x0808a391 in mono_arch_handle_altstack_exception (sigctx=0xb7bb7d0c, 
    fault_addr=0x0, stack_ovf=0) at exceptions-x86.c:854
#4  <signal handler called>
#5  0x080f3f75 in mono_class_is_assignable_from (klass=0x830cb1c, 
    oklass=0x83a6f10) at class.c:5796
#6  0xb78fd7ad in ?? ()
#7  0x0830cb1c in ?? ()
#8  0x083a6f10 in ?? ()
#9  0x00000000 in ?? ()
#0  0xffffe410 in __kernel_vsyscall ()

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.

Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.

More information about the mono-bugs mailing list