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

[bugzilla-daemon@bugzilla.ximian.com]

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-17 02:04:10.000000000 -0400
+++ shadow/56599.tmp.11912	2004-04-17 03:36:06.000000000 -0400
@@ -550,6 +550,75 @@
 acquire the domain lock in mono_jit_info_table but that lock is  
 currently head by thread 7672 (thread 2).  
   
 I will keep looking into this for a while, but figured that I would  
 post it here so that the experts could look it over.  Who knows, may  
 be nothing, but it might be helpful.  Good luck!  
+
+------- Additional Comments From joshhelmer@cox.net  2004-04-17 03:36 -------
+Just a little more info before I give it up for the night.  I can 
+verify that trampoline_hash_mutex has been aquired in frame 10 of 
+thread 3, and the system is trying to get the domain lock in frame 9 
+of thread 3. 
+ 
+I can also see that the domain lock is already held in frame 10 of 
+thread 2, and that the system is trying to acquire 
+trampoline_hash_mutex in frame 9 of thread 2.  Text book deadlock 
+example... 
+ 
+I also found that my suspicions about the gdb output being off by 4 
+bytes seem to be correct.  When I print the domain object from 
+thread 2 I get: 
+ 
+(gdb) p *domain 
+$45 = { 
+  domain = 0x809ff80, 
+  lock = { 
+    depth = 0, 
+    mutex = { 
+      __data = { 
+        __lock = 2, 
+        __count = 1, 
+        __owner = 7672, 
+        __kind = 1, 
+        __nusers = 1 
+      }, 
+      __size = 
+"\002\000\000\000\001\000\000\000ø\035\000\000\001\000\000\000\001\000\000\000\000\000\000", 
+      __align = 2 
+    } 
+  }, 
+  mp = 0x8060620, 
+  code_mp = 0x8062628, 
+  env = 0x8090f80, 
+  assemblies = 0x8062638, 
+  entry_assembly = 0x8128eb0, 
+  setup = 0x809ffc0, 
+  friendly_name = 0x8063428 "mcs.exe", 
+  state = 0, 
+  ldstr_table = 0x8090f00, 
+  class_vtable_hash = 0x8090f60, 
+  proxy_vtable_hash = 0x8090f40, 
+  static_data_hash = 0x8090f20, 
+  jit_code_hash = 0x8062688, 
+  jit_info_table = 0x804f5d4, 
+  type_hash = 0x8090ea0, 
+  refobject_hash = 0x8090d20, 
+  domain_id = 1, 
+  search_path = 0x0, 
+  create_proxy_for_type_method = 0x0, 
+  private_invoke_method = 0x0, 
+  default_context = 0x80e5fc0, 
+  out_of_memory_ex = 0x80e6fc0, 
+  null_reference_ex = 0x80e6f90, 
+  stack_overflow_ex = 0x80e6f60, 
+  special_static_fields = 0x0, 
+  jump_target_hash = 0x0, 
+  class_init_trampoline_hash = 0x8090ee0, 
+  finalizable_objects_hash = 0x80626d8 
+} 
+ 
+which makes a lot more sense than the version I see in gdb's output 
+for thread 3.  The big mystery is to figure out where the domain 
+lock has been acquired in thread 2.  At that point at least I will 
+understand exactly what has to happen before the deadlock occurs, 
+then I might finally be able to find a fix...