[Gtk-sharp-list] Access Violations with Mono.Cairo on Windows

Andy Selvig ajselvig at gmail.com
Wed Dec 30 09:21:55 EST 2009


It is marked as obsolete (at least it is in whatever version I'm using on
Linux), but from the code you linked to it simply calls the valid
constructor anyway, so it should do the exact same thing.

Plus, it does work initially. It takes a couple seconds to fail, but before
that, it renders exactly the way it should.

I've become convinced that I'm running different versions of Mono.Cairo. I
know the one on Windows says it's 2.0.0.0 and it comes from the latest
version of the Gtk# installer. I'll have to verify what version I'm using at
home on Linux, but I'm almost positive it's 2.0.0.0 as well.

On Tue, Dec 29, 2009 at 9:45 PM, Michael Hutchinson <
m.j.hutchinson at gmail.com> wrote:

> On Tue, Dec 29, 2009 at 9:20 AM, Andy Selvig <ajselvig at gmail.com> wrote:
> > Hi-
> >
> > First of all, this is a Mono.Cairo question and I've noticed there's a
> lot
> > of experience with it on this list, but if there's a better place to
> > discuss, please let me know.
> >
> > I've working on a project using Mono.Cairo. Most of my recent development
> > has been on Linux and everything is working well. However, I recently
> tried
> > to run the project on Windows and I keep getting access violations from
> > Cairo calls:
> >
> > "Attempted to read or write protected memory. This is often an indication
> > that other memory is corrupt."
> >
> > The part of the code this seems to be happening in is when I create a
> Cairo
> > image surface and render to it. It looks something like this:
> >
> >             // remake the image surface, if needed
> >             if (surface == null || surface.Width != IntWidth ||
> > surface.Height != IntHeight)
> >             {
> >                 imageData = new byte[IntWidth * IntHeight * 4];
> >                 surface = new ImageSurface( ref imageData, Format.ARGB32,
> > IntWidth, IntHeight, 4 * IntWidth);
> >             }
> >
> >             // render the control to the surface
> >             using (Context cr = new Context(surface))
> >             {
> >                 cr.Operator = Operator.Source;
> >                 cr.Color = new Cairo.Color(1, 1, 1, 0);
> >                 cr.Paint();
> >
> >                 cr.Operator = Operator.Over;
> >                 cr.MoveTo(0,0);
> >                 RenderCairo(new RenderContext(cr,
> > DecoratorService.Get(viewport)));
> >
> >                 surface.Flush();
> >             };
> >
> > This happens every render cycle and then the image data from the surface
> > gets copied to an OpenGL texture and rendered to the screen. So, there's
> no
> > direct Gtk# involved, but I run it inside a Gtk# app on Linux and a WPF
> app
> > on Windows (both using the Tao OpenGL bindings).
> >
> > The access violations seem to happen randomly, but generally within a
> couple
> > seconds of interacting with the app. It happens on either the cr.Paint()
> > call or one of the cr.Operator calls.
> >
> > One thing that I had to change to get it to compile on Windows is adding
> a
> > ref to the image data argument in the ImageSurface constructor. It
> compiles
> > and runs fine without it on Linux, but not on Windows. I'm not even sure
> how
> > this could be as I'm using the same version of Mono.Cairo (2.0.0).
> >
> > Anyway, I'm at a bit of a loss as to how to debug this issue. Obviously
> some
> > memory (the image data buffer?) is being moved or freed unintentionally
> and
> > then accessed later, but I just don't see why that would be, especially
> > since it works wonderfully on Linux. Any help would be appreciated.
>
> The "ref" version of the ctor is obsolete:
>
> http://anonsvn.mono-project.com/viewvc/trunk/mcs/class/Mono.Cairo/Mono.Cairo/ImageSurface.cs
>
> Because the obsoleted version does nothing, that means that the
> ImageSurface's "surface" pointer is zero, so code that dereferences it
> will explode.
>
> --
> Michael Hutchinson
> http://mjhutchinson.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/gtk-sharp-list/attachments/20091230/247914be/attachment-0001.html 


More information about the Gtk-sharp-list mailing list