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 [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=78782 --- shadow/78782 2006-07-09 11:10:47.000000000 -0400 +++ shadow/78782.tmp.4872 2006-07-09 14:50:29.000000000 -0400 @@ -407,6 +407,145 @@ #21 0x100d2fa0 in mini_init (filename=0x7fe2fa28 "../class/lib/monolite/mcs.exe") at mini.c:10492 #22 0x10014574 in mono_main (argc=13, argv=<value optimized out>) at driver.c:867 #23 0x10013ae0 in main (argc=13, argv=0x7fe2f844) at main.c:12 + +------- Additional Comments From [EMAIL PROTECTED] 2006-07-09 14:50 ------- +Ok, please ignore everything noted above. As "make clean" doesn't do +what it should I built everything from a broken source tree and +additionally the g_malloc -> codeman "fix" only breaks everything harder. + +In any case there are still 3 places where malloc() (or realloc()) is +used for code on PPC: +- mono_debugger_create_notification_function() +- mono_arch_emit_prolog() +- mono_arch_emit_epilog() + + +So here's the current state: + +When running mono (1.1.13.8 or 1.1.16) on linux/ppc with glibc 2.4 and +a libgcc_s.so.1 (from gcc 4.1.1) compiled with SSP mono segfaults +always. mono works when using a non-SSP libgcc_s.so.1. + +Also it works fine on x86, sparc, amd64 and ia64 with the same +environment. + +The segfault happens every time mono is running an assembly, mono +--help for example works. Building mono obviously doesn't work. + +Parameters to configure are --with-gc=included --with-tls=__thread. +When using --with-gc=none everything works fine. When using +--with-gc=boehm (using the system libgc that definitely works and +doesn't crash inkscape for example) one gets the same segfault again. +Using --with-tls=pthread gives exactly the same results. + +Output of mono: +================================================================= +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: + + +================================================================= +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: +[and so on] + + +Running it in gdb gives the following insights: + +Program received signal SIGSEGV, Segmentation fault. +0x0fb58604 in _Unwind_FindEnclosingFunction () from /lib/libgcc_s.so.1 +(gdb) bt +#0 0x0fb58604 in _Unwind_FindEnclosingFunction () from /lib/libgcc_s.so.1 +#1 0x0fb5941c in __frame_state_for () from /lib/libgcc_s.so.1 +#2 0x0fb59f64 in _Unwind_ForcedUnwind () from /lib/libgcc_s.so.1 +#3 0x0fe6c458 in _Unwind_ForcedUnwind () from /lib/libpthread.so.0 +#4 0x0fe696a4 in __pthread_unwind () from /lib/libpthread.so.0 +#5 0x0fe696a4 in __pthread_unwind () from /lib/libpthread.so.0 +#6 0x0fe696a4 in __pthread_unwind () from /lib/libpthread.so.0 +#7 0x0fe696a4 in __pthread_unwind () from /lib/libpthread.so.0 +#8 0x0fe696a4 in __pthread_unwind () from /lib/libpthread.so.0 +#9 0x0fe696a4 in __pthread_unwind () from /lib/libpthread.so.0 +#10 0x0fe696a4 in __pthread_unwind () from /lib/libpthread.so.0 +Previous frame inner to this frame (corrupt stack?) + +Now setting a breakpoint on __pthread_unwind() gives the following: +Breakpoint 2, 0x0fe69668 in __pthread_unwind () from /lib/libpthread.so.0 +(gdb) bt +#0 0x0fe69668 in __pthread_unwind () from /lib/libpthread.so.0 +#1 0x0fe62e34 in pthread_exit () from /lib/libpthread.so.0 +#2 0x100c6550 in thread_exit (exitstatus=0, handle=0x408) at +threads.c:146 +#3 0x100c66b8 in thread_start_routine (args=0x30498db8) at threads.c:194 +#4 0x100e1328 in GC_start_routine (arg=<value optimized out>) at +pthread_support.c:1331 +#5 0x0fe61ab8 in start_thread () from /lib/libpthread.so.0 +#6 0x0fe61ab8 in start_thread () from /lib/libpthread.so.0 +Previous frame inner to this frame (corrupt stack?) + +This is the only time __pthread_unwind() is called and doing a "cont" +gives the same segfault as above again. +When setting a breakpoint on GC_start_routine() one can see that this +is the one and only time that it is called. + +Running mono with --trace gives the following: +[...] +LEAVE: (wrapper runtime-invoke) System.Object:runtime_invoke_void +(object,intptr,intptr,intptr)[OBJECT:(nil)] +ENTER: (wrapper runtime-invoke) System.Object:runtime_invoke_void +(object,intptr,intptr,intptr)() ip: 0x101044c8 +. ENTER: System.IO.StreamWriter:Finalize ()() ip: 0x30c40dd0 +. . ENTER: System.IO.StreamWriter:Dispose (bool)() ip: 0x30c40f08 +. . LEAVE: System.IO.StreamWriter:Dispose (bool) +. . ENTER: System.Object:Finalize ()() ip: 0x30c40f20 +. . LEAVE: System.Object:Finalize () +. LEAVE: System.IO.StreamWriter:Finalize () +LEAVE: (wrapper runtime-invoke) System.Object:runtime_invoke_void +(object,intptr,intptr,intptr)[OBJECT:(nil)] +ENTER: (wrapper runtime-invoke) System.Object:runtime_invoke_void +(object,intptr,intptr,intptr)() ip: 0x101044c8 +. ENTER: System.Threading.Thread:Finalize ()() ip: 0x30c40dd0 +. . ENTER: System.IntPtr:op_Explicit (int)() ip: 0x30c41410 +. . . ENTER: System.IntPtr:.ctor (int)() ip: 0x30c4151c +. . . LEAVE: System.IntPtr:.ctor (int) +. . LEAVE: System.IntPtr:op_Explicit (int)result=0 +. . ENTER: (wrapper managed-to-native) +System.Threading.Thread:Thread_free_internal (intptr)() ip: 0x30c41434 +. . LEAVE: (wrapper managed-to-native) +System.Threading.Thread:Thread_free_internal (intptr) +. . ENTER: System.Object:Finalize ()() ip: 0x30c4144c +. . LEAVE: System.Object:Finalize () +. LEAVE: System.Threading.Thread:Finalize () +LEAVE: (wrapper runtime-invoke) System.Object:runtime_invoke_void +(object,intptr,intptr,intptr)[OBJECT:(nil)] +ENTER: (wrapper runtime-invoke) System.Object:runtime_invoke_void +(object,intptr,intptr,intptr)() ip: 0x101044c8 +. ENTER: System.IO.StreamWrite +================================================================= +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: +[...] + + +gzipped valgrind output is attached but when comparing the output to +one generated on x86 this (repeated many times on different addresses) +looks suspicious: +Address 0x7EF70768 is just below the stack ptr. To suppress, use: +--workaround-gcc296-bugs=yes. + +Bye + _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
