[Mono-bugs] [Bug 31174][Cri] Changed - Race condition and early calling of finalizers

bugzilla-daemon@rocky.ximian.com bugzilla-daemon@rocky.ximian.com
25 Sep 2002 06:19:34 -0000


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@ximian.com.

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

--- shadow/31174	Tue Sep 24 22:52:56 2002
+++ shadow/31174.tmp.7671	Wed Sep 25 02:19:34 2002
@@ -3,21 +3,21 @@
 Version: unspecified
 OS: other
 OS Details: 
 Status: NEW   
 Resolution: 
 Severity: Unknown
-Priority: Major
+Priority: Critical
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: gonzalo@ximian.com               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
 URL: 
-Cc: 
-Summary: [XSP] internalStream and internalEncoding are null in StreamWriter!!!
+Cc: dick@ximian.com,lupus@ximian.com
+Summary: Race condition and early calling of finalizers
 
 Description of Problem:
 
 When running xsp server i get a NullReferenceException. If it isn't throwed
 at startup, it's throwed on first request.
 
@@ -52,7 +52,61 @@
 
 ------- Additional Comments From gonzalo@ximian.com  2002-09-24 22:44 -------
 It seems to be a problem in Console.Write* because mono server.exe
 does not even display the "Started processing..." line.
 
 It works fine with mint.
+
+
+------- Additional Comments From miguel@ximian.com  2002-09-25 02:19 -------
+There seems to be some kind of race, I get very different results
+depending on the run (and this might be related to the bug that I CCed
+Dick on).
+
+Something seems to be disposing objects before they are used with Mono
+(I have not reproduced this with mint yet, but given that it seems
+race-condition bound, that might explain why).
+
+I had a puts (using PInvoke) in StreamWriter.Dispose and had all
+StreamWriters identified.  I had stdin (id == 3) be disposed, which is
+what sets the internalEncoding and internalStream values to null.
+
+Another time I saw this:
+
+
+Unhandled Exception: System.ObjectDisposedException: The object was
+used after being disposed
+in <0x00060> 00 System.Net.Sockets.TcpClient:CheckDisposed ()
+in <0x0002a> 00 System.Net.Sockets.TcpClient:GetStream ()
+in <0x00042> 00 Mono.ASP.Worker:Run ()
+in <0x00057> 01 System.MulticastDelegate:invoke_void ()
+
+This is because the TcpClient code has explicit code that checks for
+re-incarnated objects (objects being used which were already disposed). 
+
+The stack trace from the Dispose() routine is not very useful though:
+
+	at System.IO.StreamWriter.Dispose()
+	at System.IO.StreamWriter.Finalize()
+	at System.IO.StreamWriter.Finalize()
+	at System.Diagnostics.StackFrame.get_frame_info()
+	at System.Diagnostics.StackFrame.get_frame_info()
+	at System.Diagnostics.StackFrame..ctor()
+	at System.Diagnostics.StackTrace.init_frames()
+	at System.Diagnostics.StackTrace..ctor()
+	at System.IO.StreamWriter.Dispose()
+	at System.IO.StreamWriter.Finalize()
+	at System.IO.StreamWriter.Finalize()
+Destroying: 3
+
+(that last bit was my debugging message)
+
+Some other (random times), I will get:
+mono$ MONO_PATH=/cvs/mcs/class/lib mono --noinline server.exe  20001
+Remember that you should rerun the server if you change
+the aspx file!
+Server started.
+Unhandled Exception: System.NullReferenceException: A null value was
+found where an object instance was required
+in <0x0003b> 00 Mono.ASP.Server:RunServer ()
+in <0x00057> 01 System.MulticastDelegate:invoke_void ()