[Mono-bugs] [Bug 78168][Maj] New - Unloading then reloading an assembly causes segfault

[bugzilla-daemon at 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 colin at breame.net.

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

--- shadow/78168	2006-04-22 18:32:12.000000000 -0400
+++ shadow/78168.tmp.22739	2006-04-22 18:32:12.000000000 -0400
@@ -0,0 +1,48 @@
+Bug#: 78168
+Product: Mono: Runtime
+Version: 1.1
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Major
+Component: misc
+AssignedTo: mono-bugs at ximian.com                            
+ReportedBy: colin at breame.net               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Summary: Unloading then reloading an assembly causes segfault
+
+I have a system that dynamically compiles assemblies.  Once compiled, it      
+loads the new assembly into an app domain (using      
+CreateInstanceFromAndUnWrap).  Once it detects that the source has changed   
+the system:   
+ a) unloads the app domain   
+ b) compiles the source into a new assembly (which has the same assembly 
+filename and classname) 
+ c) reloads into a new appdomain and instantiates the object 
+(CreateInstanceFromAndUnwrap) 
+However, when (c) happens mono does a SIGSEGV.      
+      
+I've tried all manner of simplified test causes to try to demonstrate this      
+phenomena but they all work.  I have got part of a stack trace from gdb    
+(the complete stack trace was huge and contained no symbols - it might 
+even have been corrupt): 
+    
+#0  0x4023d4e2 in __malloc_initialize_hook () from /lib/tls/libc.so.6    
+#1  0x40044ef7 in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0    
+#2  0x0809b498 in mono_class_from_name (image=0x4023d230,    
+    name_space=0x8acec20 "views.home", name=0x8acec2b "index_view_t")    
+    at class.c:3856    
+#3  0x080d6191 in mono_reflection_get_type_internal (image=0x4023d230,    
+    info=0x419239b0, ignorecase=0) at reflection.c:6304    
+#4  0x080d61db in mono_reflection_get_type (image=0x1, info=0x419239b0,    
+    ignorecase=0, type_resolve=0x419239ac) at reflection.c:6395    
+#5  0x0814737e in ves_icall_System_Reflection_Assembly_InternalGetType (    
+    assembly=0x18fc90, module=0x0, name=0x20bbc0, throwOnError=1 '\001',    
+    ignoreCase=0 '\0') at icall.c:3643    
+    
+I can provide the actual application if required (it's a couple of megs) 
+and instructions on how to reproduce the fault.