[Mono-bugs] [Bug 458947] New: SEGFAULT when from within a generic class a method of another class is called , wich throws an eception

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Sat Dec 13 23:41:05 EST 2008


           Summary: SEGFAULT when from within a generic class a method of
                    another class is called, wich throws an eception
           Product: Mono: Runtime
           Version: 2.2.x
          Platform: x86-64
        OS/Version: Linux
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: generics
        AssignedTo: mono-bugs at lists.ximian.com
        ReportedBy: mono at e-tobi.net
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---

Created an attachment (id=259952)
 --> (https://bugzilla.novell.com/attachment.cgi?id=259952)
Fixes the bug by setting the generic sharing mode to CORLIB again

This bug hit me when porting StructureMap to Mono and it was really hard to
find, because there was no usable stack trace and the method that caused the
problem was buried deep in the call hierarchy and in the end even was some
emitted code.

But I manged to put this into a very simple test case:

public class TestClass<T>
    public void Test()
            new SomeClass().ThrowAnException();

public class SomeClass
    public void ThrowAnException()
        throw new Exception("Something went wrong");

public class MainClass
    public static void Main()
        new TestClass<string>().Test();

What happens here is, that a generic class calls another classes method, which
throws an exception that causes a SEGFAULT in the runtime (see below).

This happens ONLY if:

a) The calling class is generic
b) The method that throws is on another class
c) try / catch is used in the generic class

The bug is in 2.2 as well as in the trunk. It was introduced with revision
114108: "class.c (mono_class_generic_sharing_enabled): Experimentally change
the default generic sharing mode to 'all'".

Reverting this commit (which is just a one-liner, see the attached patch) fixes
the problem.

Here's the runtime error, when you execute the above code:

[mono-trunk] /tmp/structuremap/build @ mono --debug ./test2.exe

Native stacktrace:

        mono [0x47da70]
        mono [0x4adaed]
        /lib/libpthread.so.0 [0x7f0c9bce5a80]
        mono [0x47cbb2]
        mono [0x47caa5]
        mono(mono_amd64_throw_exception+0x139) [0x4ae959]

Debug info from gdb:

[Thread debugging using libthread_db enabled]
[New Thread 0x7f0c9c9be720 (LWP 8790)]
[New Thread 0x41a58950 (LWP 8792)]
[New Thread 0x41b99950 (LWP 8791)]
0x00007f0c9b7cd269 in syscall () from /lib/libc.so.6
  3 Thread 0x41b99950 (LWP 8791)  0x00007f0c9bce50e1 in nanosleep () from
  2 Thread 0x41a58950 (LWP 8792)  0x00007f0c9bce3bd1 in sem_wait () from
  1 Thread 0x7f0c9c9be720 (LWP 8790)  0x00007f0c9b7cd269 in syscall () from

Thread 3 (Thread 0x41b99950 (LWP 8791)):
#0  0x00007f0c9bce50e1 in nanosleep () from /lib/libpthread.so.0
#1  0x00000000005566b2 in collection_thread (unused=<value optimized out>) at
#2  0x00007f0c9bcddfc7 in start_thread () from /lib/libpthread.so.0
#3  0x00007f0c9b7d05ad in clone () from /lib/libc.so.6
#4  0x0000000000000000 in ?? ()

Thread 2 (Thread 0x41a58950 (LWP 8792)):
#0  0x00007f0c9bce3bd1 in sem_wait () from /lib/libpthread.so.0
#1  0x000000000052707a in finalizer_thread (unused=<value optimized out>) at
#2  0x0000000000510613 in start_wrapper (data=<value optimized out>) at
#3  0x00000000005587eb in thread_start_routine (args=0x21302f8) at
#4  0x000000000056e9c2 in GC_start_routine (arg=0x7f0c9c869e70) at
#5  0x00007f0c9bcddfc7 in start_thread () from /lib/libpthread.so.0
#6  0x00007f0c9b7d05ad in clone () from /lib/libc.so.6
#7  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f0c9c9be720 (LWP 8790)):
#0  0x00007f0c9b7cd269 in syscall () from /lib/libc.so.6
#1  0x000000000047db72 in mono_handle_native_sigsegv (signal=7, ctx=<value
optimized out>) at mini-exceptions.c:1406
#2  0x00000000004adaed in mono_arch_handle_altstack_exception
(sigctx=0x7f0c9c863c40, fault_addr=<value optimized out>, stack_ovf=0) at
#3  <signal handler called>
#4  0x000000000047cbb2 in mono_handle_exception_internal (ctx=0x7fffa49df1e0,
obj=0x7f0c9c80bde0, original_ip=<value optimized out>, test_only=1,
    at mini-exceptions.c:755
#5  0x000000000047caa5 in mono_handle_exception_internal (ctx=0x7fffa49df2d0,
obj=0x7f0c9c80bde0, original_ip=0x41b8655c, test_only=0, out_filter_idx=0x0) at
#6  0x00000000004ae959 in mono_amd64_throw_exception (dummy1=<value optimized
out>, dummy2=<value optimized out>, dummy3=<value optimized out>, dummy4=<value
optimized out>, 
    dummy5=<value optimized out>, dummy6=<value optimized out>,
exc=0x7f0c9c80bde0, rip=1102603612, rsp=140735955203056, rbx=0,
rbp=140735955203136, r12=34576784, r13=0, 
    r14=139692142398464, r15=0, rdi=139692142018016, rsi=139692142042960,
rax=139692142018016, rcx=1102602688, rdx=0, rethrow=0) at
#7  0x0000000041849b36 in ?? ()
#8  0x00007f0c9c80bde0 in ?? ()
#9  0x0000000041b8655c in ?? ()
#10 0x00007fffa49df3f0 in ?? ()
#11 0x0000000000000000 in ?? ()
#0  0x00007f0c9b7cd269 in syscall () from /lib/libc.so.6

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