[Mono-bugs] [Bug 81153][Nor] Changed - Regression in MDI drawing.

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Tue Mar 20 11:01:58 EDT 2007


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 sebastien at ximian.com.

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

--- shadow/81153	2007-03-20 05:24:05.000000000 -0500
+++ shadow/81153.tmp.4244	2007-03-20 10:01:58.000000000 -0500
@@ -96,6 +96,30 @@
 
 
 ------- Additional Comments From rolfkvinge at ya.com  2007-03-20 05:24 -------
 Chris, I don't think we can track the Graphics on the SWF side, since 
 the application can call Graphics.FromHwnd(Control.Handle) directly 
 and then we're lost.
+
+------- Additional Comments From sebastien at ximian.com  2007-03-20 10:01 -------
+I don't like keeping a list a Graphics instances. It *may* fixes some
+problem if we're having a finalizer execution ordering problem but the
+issue can be duplicated (without MONO_XSYNC) outside this case.
+
+I can also duplicate the issue (at least the X errors) by doing
+
+	Graphics g = Graphics.FromHwnd (FileButton.Handle);
+	FileButton.Dispose ();
+	g.DrawLine (Pens.Red, 0, 0, 10, 10);
+	g.Dispose ();
+
+inside Paint. Of course this would fail too (but differently,
+ExternalException) under MS runtime, but Mono's
+ObjectDisposedException can only be throw if the managed code is aware
+that the X handle is freed/invalid. 
+
+This also explains why moving the Dispose of the Graphics instances
+earlier "hides" the problem (the X handle is still valid at that time,
+but not later).
+
+Note: running this sample under valgrind didn't report anything useful
+(well it's useful to know it's not a memory corruption).


More information about the mono-bugs mailing list