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 [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=77824 --- shadow/77824 2006-05-21 16:29:18.000000000 -0400 +++ shadow/77824.tmp.32042 2006-05-22 18:03:35.000000000 -0400 @@ -1,13 +1,13 @@ Bug#: 77824 Product: Mono: Class Libraries Version: 1.1 OS: unknown OS Details: -Status: REOPENED -Resolution: +Status: RESOLVED +Resolution: NOTABUG Severity: Unknown Priority: Normal Component: Windows.Forms AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] @@ -235,6 +235,25 @@ Personally I dislike the g_return_val_if_fail calls - in part because they mess up the unit tests display, coverity has a hard time dealing with them (and reporting false alarms) and, in some case, introduced problem when dealing with errors (e.g. missing free). But removing them won't fix your problem (only the display ;-) + +------- Additional Comments From [EMAIL PROTECTED] 2006-05-22 18:03 ------- +After lots of analyzing here's what I found: + +Inside it's OnPaint(paint_event) handler the application does: +new PaintEventArgs(paint_event.Graphics, rectangle) + +That causes the graphics object to be copied into a new +PaintEventArgs object, and when the GC cleans up that object, the +graphics object will be disposed. In some cases, this object, +however, is represending the double buffer context and may not be +disposed. If it is anyways, we get a later crash since it's native +object is now 0. + +The problem is that just creating new PaintEventArgs is not really +legal, even on MS. If the GC on MS were to kick in at the right time, +the graphics object would be disposed there, too, and the app would +crash. Since we reuse our graphics object it just is more obvious on +Mono. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
