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=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 [EMAIL PROTECTED] 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. + + _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
