[Mono-bugs] [Bug 80532][Wis] Changed - svn head - segfault in the runtime while running mojoportal 2.x

Sat Jan 27 15:04:51 EST 2007

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 miguel at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=80532

--- shadow/80532	2007-01-27 13:18:04.000000000 -0500
+++ shadow/80532.tmp.13991	2007-01-27 15:04:51.000000000 -0500
@@ -545,6 +545,120 @@
 with mono_errata/Web.config again. Probably simpler just to remove the
 Deploy project.
 
 Thanks again for your help,
 
 Joe
+
+------- Additional Comments From miguel at ximian.com  2007-01-27 15:04 -------
+I can reproduce the issue with the instructions provided
+
+I have uploaded a ready-to-run directory here:
+
+http://primates.ximian.com/~miguel/Web.tar.gz
+
+cd into that, and run `xsp2'
+
+I get this error in x86:
+
+
+#0  GC_clear_stack_inner (arg=0x0, limit=3063730880) at misc.c:293
+#1  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063730880) at
+misc.c:295
+#2  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063730880) at
+misc.c:295
+#3  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063730880) at
+misc.c:295
+#4  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063730880) at
+misc.c:295
+#5  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063730880) at
+misc.c:295
+#6  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063730880) at
+misc.c:295
+#7  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063730880) at
+misc.c:295
+#8  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063730880) at
+misc.c:295
+#9  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063730880) at
+misc.c:295
+#10 0x08125816 in GC_clear_stack (arg=0x0) at misc.c:341
+#11 0x081295fd in GC_local_malloc (bytes=148) at pthread_support.c:346
+#12 0x08099af4 in mono_array_new_specific (vtable=0x84d7a18, n=11) at
+object.c:2616
+
+On a separate run, I get this somewhere else:
+
+#0  GC_clear_stack_inner (arg=0x0, limit=3063964064) at misc.c:293
+#1  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063964064) at
+misc.c:295
+#2  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063964064) at
+misc.c:295
+#3  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063964064) at
+misc.c:295
+#4  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063964064) at
+misc.c:295
+#5  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063964064) at
+misc.c:295
+#6  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063964064) at
+misc.c:295
+#7  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063964064) at
+misc.c:295
+#8  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063964064) at
+misc.c:295
+#9  0x081257a6 in GC_clear_stack_inner (arg=0x0, limit=3063964064) at
+misc.c:295
+#10 0x08125816 in GC_clear_stack (arg=0x0) at misc.c:341
+#11 0x0812952f in GC_local_malloc_atomic (bytes=38) at
+pthread_support.c:371
+#12 0x08099c5b in mono_string_new_size (domain=0x21258, len=12) at
+object.c:2633
+#13 0x080db76a in ves_icall_System_String_InternalAllocateStr
+(length=12) at string-icalls.c:645
+
+I cant use mono_pmip, but I used mono -v to look at the Emitted
+locations, and this is what the stack trace looks above:
+
+Method (wrapper managed-to-native) System.String:InternalAllocateStr
+(int) emitted at 0xb69fd240 to 0xb69fd28b (code length 75)
+[ASPHOST_7c2ad03b]^M
+Method System.String:StartsWith
+(string,bool,System.Globalization.CultureInfo) emitted at 0xb6989a10
+to 0xb6989a7b (code length 107) [ASPHOST_7c2ad03b]^M
+Method (wrapper managed-to-native) System.String:InternalAllocateStr
+(int) emitted at 0xb69fd240 to 0xb69fd28b (code length 75)
+[ASPHOST_7c2ad03b]^M
+Method System.String:Substring (int) emitted at 0xb69d4920 to
+0xb69d49ec (code length 204) [ASPHOST_7c2ad03b]^M
+Method System.String:StartsWith (string) emitted at 0xb69899d0 to
+0xb69899fa (code length 42) [ASPHOST_7c2ad03b]^M
+
+info thread:
+(gdb) info thread
+  9 Thread -1231729760 (LWP 13210)  0xffffe410 in __kernel_vsyscall ()
+* 8 Thread -1229956192 (LWP 13209)  GC_clear_stack_inner (arg=0x0,
+limit=3063964064) at misc.c:293
+  7 Thread -1226998880 (LWP 13208)  0xffffe410 in __kernel_vsyscall ()
+  6 Thread -1224676448 (LWP 13207)  0xffffe410 in __kernel_vsyscall ()
+  5 Thread -1225794656 (LWP 13205)  0xffffe410 in __kernel_vsyscall ()
+  4 Thread -1224676448 (LWP 13207)  0xffffe410 in __kernel_vsyscall ()
+  3 Thread -1220117600 (LWP 13203)  0xffffe410 in __kernel_vsyscall ()
+  2 Thread -1209226336 (LWP 13202)  0xffffe410 in __kernel_vsyscall ()
+  1 Thread -1210698048 (LWP 13199)  0xffffe410 in __kernel_vsyscall ()
+
+
+Google finds this information about this particular problem:
+
+http://blog.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/month=20060401/page=2
+
+From Hans Boehm on that thread:
+
+This usually means that you are invoking the collector from a stack
+that the collector doesn't know about,
+e.g. because the collector is configured without threads, but you have
+a multithreaded application.
+GC_clear_stack_inner() is supposed to recurse, clearing a local array,
+until it hits a limit.  This is
+designed to overwrite old values on the stack occasionally.  In this
+case I expect that the limit is far
+removed from the current stack pointer, and probably in a different stack.
+
+
