[Mono-bugs] [Bug 56599][Nor] Changed - mcs compile hangs

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Mon, 12 Apr 2004 00:52:44 -0400 (EDT)
Previous message: [Mono-bugs] [Bug 56821][Wis] Changed - Constant folding is not done on true || x
Next message: [Mono-bugs] [Bug 56825][Cri] New - Error while serializing a class
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 joshhelmer@cox.net.

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

--- shadow/56599	2004-04-10 15:33:31.000000000 -0400
+++ shadow/56599.tmp.9540	2004-04-12 00:52:44.000000000 -0400
@@ -1,12 +1,12 @@
 Bug#: 56599
 Product: Mono: Compilers
 Version: unspecified
-OS: unknown
+OS: other
 OS Details: Gentoo Linux - 2.6.3-gentoo-r1 kernel with NTPL
-Status: NEEDINFO   
+Status: REOPENED   
 Resolution: 
 Severity: Unknown
 Priority: Normal
 Component: C#
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: joshhelmer@cox.net               
@@ -102,6 +102,216 @@
 (gdb) p print_method_from_ip (0x2342342)
 
 Miguel
 
 ------- Additional Comments From miguel@ximian.com  2004-04-10 15:33 -------
 setting to needinfo, please reopen when you have the data
+
+------- Additional Comments From joshhelmer@cox.net  2004-04-12 00:52 -------
+I don't know how helpful this will be, but here is what I got: 
+ 
+(gdb) bt 
+#0  0xffffe410 in ?? () 
+#1  0xbfffc9f8 in ?? () 
+#2  0x000002b7 in ?? () 
+#3  0x00000000 in ?? () 
+#4  0x40bd3260 in pthread_cond_timedwait@@GLIBC_2.3.2 () 
+   from /lib/libpthread.so.0 
+#5  0x400ec72f in _wapi_handle_wait_signal_handle 
+(handle=0xfffffffc) 
+    at handles-private.h:87 
+#6  0x400f66fd in WaitForSingleObject (handle=0x8, 
+timeout=4294967295) 
+    at wait.c:95 
+#7  0x400f6c86 in WaitForMultipleObjects (numobjects=1, 
+handles=0x813ccb8, 
+    waitall=1, timeout=4294967295) at wait.c:325 
+#8  0x400bad72 in wait_for_tids (wait=0x813ccb8, timeout=4294967292) 
+    at threads.c:1097 
+#9  0x400baed3 in mono_thread_manage () at threads.c:1193 
+#10 0x4009a52e in mono_runtime_exec_managed_code (domain=0xfffffffc, 
+    main_func=0xfffffffc, main_args=0xfffffffc) at object.c:1314 
+#11 0x400740e3 in mono_main (argc=9, argv=0xbfffccb4) at 
+driver.c:788 
+#12 0x08048f5f in main (argc=-4, argv=0xfffffffc) at main.c:6 
+(gdb) info threads 
+  3 Thread 1095887792 (LWP 5248)  0xffffe410 in ?? () 
+  2 Thread 1104104368 (LWP 5250)  0xffffe410 in ?? () 
+  1 Thread 1088363600 (LWP 5235)  0xffffe410 in ?? () 
+(gdb) thread 2 
+[Switching to thread 2 (Thread 1104104368 (LWP 5250))]#0  0xffffe410 
+in ?? () 
+(gdb) bt 
+#0  0xffffe410 in ?? () 
+#1  0x41cf3f54 in ?? () 
+#2  0x00000002 in ?? () 
+#3  0x00000000 in ?? () 
+#4  0x40bd53ab in __lll_mutex_lock_wait () from /lib/libpthread.so.0 
+#5  0x40bd2717 in _L_mutex_lock_75 () from /lib/libpthread.so.0 
+#6  0x41cf3f44 in ?? () 
+#7  0x40bd28c4 in pthread_mutex_unlock () from /lib/libpthread.so.0 
+#8  0x400e7da1 in LeaveCriticalSection (section=0x4016a084) 
+    at critical-sections.c:158 
+#9  0x400e7d48 in EnterCriticalSection (section=0x4016a080) 
+    at critical-sections.c:140 
+#10 0x40051529 in mono_create_jump_trampoline (domain=0x40bd53ab, 
+    method=0x8196838, add_sync_wrapper=1) at mini.c:6284 
+#11 0x4003b872 in mono_ldftn (method=0x40bd9a48) at jit-icalls.c:20 
+#12 0x41316024 in ?? () 
+#13 0x08196838 in ?? () 
+#14 0x41cf4608 in ?? () 
+#15 0x0813c7d8 in ?? () 
+#16 0x080f1950 in ?? () 
+#17 0x41cf3ff0 in ?? () 
+#18 0x00000000 in ?? () 
+#19 0x41646157 in ?? () 
+#20 0x40168c50 in __JCR_LIST__ () 
+   from /var/tmp/portage/mono-0.31/work/mono-0.31/mono/mini/.libs/libmono.so.0 
+#21 0x41316004 in ?? () 
+#22 0x41cf4020 in ?? () 
+#23 0x41d0c168 in ?? () 
+#24 0x08196838 in ?? () 
+#25 0x41646157 in ?? () 
+#26 0x41cf4020 in ?? () 
+#27 0x40054c6e in mono_jit_compile_method (method=0xfffffffc) at 
+mini.c:8016 
+Previous frame inner to this frame (corrupt stack?) 
+(gdb) thread 3 
+[Switching to thread 3 (Thread 1095887792 (LWP 5248))]#0  0xffffe410 
+in ?? () 
+(gdb) bt 
+#0  0xffffe410 in ?? () 
+#1  0x4151e828 in ?? () 
+#2  0x00000002 in ?? () 
+#3  0x00000000 in ?? () 
+#4  0x40bd53ab in __lll_mutex_lock_wait () from /lib/libpthread.so.0 
+#5  0x40bd2717 in _L_mutex_lock_75 () from /lib/libpthread.so.0 
+#6  0x00000001 in ?? () 
+#7  0x00000020 in ?? () 
+#8  0x080cdee0 in ?? () 
+#9  0x4151e840 in ?? () 
+#10 0x40168c50 in __JCR_LIST__ () 
+   from /var/tmp/portage/mono-0.31/work/mono-0.31/mono/mini/.libs/libmono.so.0 
+#11 0x080cdedc in ?? () 
+#12 0x4151e848 in ?? () 
+#13 0x400e7d48 in EnterCriticalSection (section=0x80cdee0) 
+    at critical-sections.c:140 
+Previous frame identical to this frame (corrupt stack?) 
+ 
+In most cases the print_method_from_ip() doesn't do much good, but 
+here are the results I see: 
+ 
+Thread 2: (sorry about the goofy order) 
+#26: No method at 0x41cf4020 
+#25: No method at 0x41646157 
+#24: No method at 0x8196838 
+#23: IP 0x41d0c168 at offset 0x20 of method (wrapper runtime-invoke) 
+Mono.CSharp.Namespace:.cctor (object,intptr,intptr) (0x41d0c148 
+0x41d0c1c8) 
+#22: No method at 0x41cf4020 
+#21: IP 0x41316004 at offset 0x4 of method (wrapper 
+managed-to-native) System.Object:__icall_wrapper_mono_ldftn (intptr) 
+(0x41316000 0x41316037) 
+#19: No method at 0x41646157 
+#18: No method at (nil) 
+#17: No method at 0x41cf3ff0 
+#16: No method at 0x80f1950 
+#15: No method at 0x813c7d8 
+#14: No method at 0x41cf4608 
+#13: No method at 0x8196838 
+#12: IP 0x41316024 at offset 0x24 of method (wrapper 
+managed-to-native) System.Object:__icall_wrapper_mono_ldftn (intptr) 
+(0x41316000 0x41316037) 
+#6:  No method at 0x41cf3f44 
+#3:  No method at (nil) 
+#2:  No method at (nil) 
+#1:  No method at 0xffffe410 
+ 
+Thread 3: 
+Any attempt to execute the method here causes the debugger to hang.  
+When I Ctrl+C the debugger and re-examine the stack trace I get: 
+ 
+#0  0xffffe410 in ?? () 
+#1  0x4151e6a0 in ?? () 
+#2  0x00000002 in ?? () 
+#3  0x00000000 in ?? () 
+#4  0x40bd53ab in __lll_mutex_lock_wait () from /lib/libpthread.so.0 
+#5  0x40bd2717 in _L_mutex_lock_75 () from /lib/libpthread.so.0 
+#6  0x40c79839 in _int_free () from /lib/libc.so.6 
+#7  0x400e7d48 in EnterCriticalSection (section=0x80cdedc) 
+    at critical-sections.c:140 
+#8  0x400cf818 in mono_jit_info_table_find (domain=0x80cded8, 
+    addr=0x4151e764 "\204çQAH}\016@àÞ\f\b¥\001") at domain.c:78 
+#9  0x4003c3f6 in print_method_from_ip (ip=0x4151e764) at mini.c:212 
+#10 <function called from gdb> 
+#11 0xffffe410 in ?? () 
+#12 0x4151e764 in ?? () 
+#13 0x00000002 in ?? () 
+#14 0x00000000 in ?? () 
+#15 0x40bd53ab in __lll_mutex_lock_wait () from /lib/libpthread.so.0 
+#16 0x40bd2717 in _L_mutex_lock_75 () from /lib/libpthread.so.0 
+#17 0x00001358 in ?? () 
+#18 0x08239a10 in ?? () 
+#19 0x00000006 in ?? () 
+#20 0x0000002d in ?? () 
+#21 0x40168c50 in __JCR_LIST__ () 
+   from /var/tmp/portage/mono-0.31/work/mono-0.31/mono/mini/.libs/libmono.so.0 
+#22 0x0804f5cc in ?? () 
+#23 0x4151e784 in ?? () 
+#24 0x400e7d48 in EnterCriticalSection (section=0x80cdee0) 
+    at critical-sections.c:140 
+Previous frame identical to this frame (corrupt stack?) 
+ 
+Thread 1: 
+Any attempt to use the print_method_from_ip trick hangs the 
+debugger.  It also seems to corrupt the stack for thread 1.  When I 
+try to get another trace I get this: 
+ 
+#0  0xffffe410 in ?? () 
+#1  0xbfffc90c in ?? () 
+#2  0x00000002 in ?? () 
+#3  0x00000000 in ?? () 
+#4  0x40bd53ab in __lll_mutex_lock_wait () from /lib/libpthread.so.0 
+#5  0x40bd2717 in _L_mutex_lock_75 () from /lib/libpthread.so.0 
+#6  0x00000000 in ?? () 
+#7  0x00000000 in ?? () 
+#8  0x00000000 in ?? () 
+#9  0x00000000 in ?? () 
+#10 0x40168c50 in __JCR_LIST__ () 
+   from /var/tmp/portage/mono-0.31/work/mono-0.31/mono/mini/.libs/libmono.so.0 
+#11 0x0804f5cc in ?? () 
+#12 0xbfffc92c in ?? () 
+#13 0x400e7d48 in EnterCriticalSection (section=0x80cdee0) 
+    at critical-sections.c:140 
+ 
+I am running a system with NTPL enabled.  I suspect that some of the 
+issues I am seeing stem from that. 
+ 
+I should also note that the emerge system uses the libtool version 
+of mini/mono to compile the MCS libs.  I don't know if that is SOP 
+or not. 
+ 
+Here is the actual command that is being issued by the build system 
+(note that this info is actually from a different compile attempt 
+than the the one that produced the above stack traces): 
+ 
+MONO_PATH="../../../class/lib:
+$MONO_PATH" /var/tmp/portage/mono-0.31/work/mono-0.31/mono/mini/mono  ../../../mcs/mcs.exe /r:mscorlib.dll /r:I18N.dll  
+-d:NET_1_1 -d:ONLY_1_1 
+-g /noconfig  /target:library /out:../../../class/lib/I18N.Other.dll 
+@I18N.Other.dll.sources 
+ 
+and more info: 
+ 
+cmdline:  
+lt-mono../../../mcs/mcs.exe/r:mscorlib.dll/r:I18N.dll-d:NET_1_1-d:ONLY_1_1-g/noconfig/target:library/out:../../../class/lib/I18N.Other.dll@I18N.Other.dll.source 
+ 
+exe:  
+/var/tmp/portage/mono-0.31/work/mono-0.31/mono/mini/.libs/lt-mono 
+ 
+cwd: /var/tmp/portage/mono-0.31/work/mcs-0.31/class/I18N/Other/ 
+ 
+ 
+If there is any other info that I can provide you with let me know.  
+I can reproduce this at will...  Exactly which library it will hang 
+on seems to be fairly random, but I have yet to get beyond the I18N 
+libs before the system hangs.
Previous message: [Mono-bugs] [Bug 56821][Wis] Changed - Constant folding is not done on true || x
Next message: [Mono-bugs] [Bug 56825][Cri] New - Error while serializing a class
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]