[Mono-bugs] [Bug 80756][Nor] New - Crash in System.Drawing.Graphics.ClipBounds

[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 vlad.dimitrov at gmail.com.

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

--- shadow/80756	2007-02-07 21:07:17.000000000 -0500
+++ shadow/80756.tmp.4041	2007-02-07 21:07:17.000000000 -0500
@@ -0,0 +1,76 @@
+Bug#: 80756
+Product: Mono: Class Libraries
+Version: unspecified
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: Sys.Drawing.
+AssignedTo: mono-bugs at ximian.com                            
+ReportedBy: vlad.dimitrov at gmail.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Crash in System.Drawing.Graphics.ClipBounds
+
+Please fill in this template when reporting a bug, unless you know what you
+are doing.
+Description of Problem:
+I finally reproduced that bug and figured out the reason for it.
+
+Steps to reproduce the problem:
+1. Create a custom class inheriting PrintDocument.
+2. Override OnPrintPage and get the ClipBounds property from the passed
+graphics object
+3. Create a new instance of that class and assign to the PrintController
+property a new instance of PreviewPrintController object.
+4. Call Print() of the custom PrintDocument object.
+
+Actual Results:
+"Path conversion requested 0 bytes (4194304 x 4194304). Maximum size is
+8388608 bytes." + crash
+
+Expected Results:
+not crash ...
+
+How often does this happen? 
+Always on my machine (I will explain below).
+
+Additional Information:
+
+The actualt reason for that bug is not that simple.
+1. When PrintDocument's Print() method is called it creates a Graphics
+object to pass to the virtual OnPrintPage method.
+2. That object is created by the OnStartPage method of the PrintController
+being used (in this case PreviewPrintController)
+3. PreviewPrintController does something strange while creating the
+Graphics object :
+g.ScaleTransform (e.PageSettings.PrinterResolution.X / 100.0f,
+e.PageSettings.PrinterResolution.Y / 100.0f);
+Which creates a transformation matrix for the graphics object (on my
+machine) like this:
+2 0
+0 2
+0 0
+
+Just for comaprison I tried the same code on MS.NET and the matrix was:
+1 0
+0 1
+0 0
+
+The printer used on both places is different (a fake one) but still I don't
+think MS uses that matrix this way in taht case.
+
+4. This later on while calling get_ClipBounds() of the Graphics object the
+matrix fails a check if it's empty (GdipGetClipBounds).This way
+GdipTransformRegion is called and then gdip_region_convert_to_path. This
+changes the clipping region object to type Path.
+
+5. GdipGetPathWorldBounds is called to determine the size of the region and
+it becomes is calculated as very big.
+
+6. gdip_region_bitmap_from_path tries to allocate memory for a bitmap as
+large as the region but failes.