What means: System.AccessViolationException

Hello to all, Im developing a plug in for GH, and I encountered this problem:
For sure, is something that Im not handling? any clue?
regards
C.

An unhandled exception of type ‘System.AccessViolationException’ occurred in RhinoCommon.dll
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Can you repeat the exception? Can you provide a small snippet of code that we can use to repeat the exception?

Thank you Dale,
print screen…

Like I said, can you repeat the exception? Can you provide a small snippet of code (i.e. text, not a screen shot) that we can use to repeat the exception? If we cannot repeat it here, it is unlikely we will of much help…

Hi Dale,
I am also experiencing a similar issue. It does seem somewhat repeatable, IE it always breaks at the same point. At this point there is also quite a heavy memory load, so perhaps this is unavoidable(that is to say the solution is to reduce the memory overhead, which could be due to a leak). It doesn’t always break, as the memory load isn’t always the same at this point, so that too points to memory being the issue

So my exception always occurs in a display conduit event handler. I recently ported this code from python to C# precisely so I could try to find this error; under python it simply crashed rhino(not leaving much help for debugging it). So I think this is a good sign that the problem is coming into focus.

The method is here, though I doubt this will help much.

public void DrawMachinesList(Rhino.Display.DrawEventArgs eventArgs)
{
    Rhino.Display.DisplayPipeline display = eventArgs.Display;
    Rhino.Display.RhinoViewport gvp = display.Viewport;
    foreach (AxisGeometry axis in MachineAxisList)
    {
        display.PushModelTransform(axis.Xform);
        foreach (rg.GeometryBase geometry in axis.MachineGeo)
        {
            if (geometry.ObjectType == Rhino.DocObjects.ObjectType.Point)
            {
                display.DrawPoint((geometry as rg.Point).Location, (System.Drawing.Color)geometry.UserDictionary["color"]);
            }
            else if (gvp.DisplayMode.EnglishName == "Wireframe")
            {
                if (geometry.ObjectType == Rhino.DocObjects.ObjectType.Mesh)
                {
                    display.DrawMeshWires((geometry as rg.Mesh), (System.Drawing.Color)geometry.UserDictionary["color"]);
                }
                else if (geometry.ObjectType == Rhino.DocObjects.ObjectType.Brep)
                {
                    display.DrawBrepWires((geometry as rg.Brep), (System.Drawing.Color)geometry.UserDictionary["color"]);
                }
            }
            else
            {
                DefaultMaterial.Diffuse = (System.Drawing.Color)geometry.UserDictionary["color"];
                if (geometry.ObjectType == Rhino.DocObjects.ObjectType.Mesh)
                {
                    display.DrawMeshShaded((geometry as rg.Mesh), DefaultMaterial);
                }
                else if (geometry.ObjectType == Rhino.DocObjects.ObjectType.Brep)
                {
                    display.DrawBrepShaded((geometry as rg.Brep), DefaultMaterial);
                }
            }
        }
        display.PopModelTransform();
    }
    foreach (rg.Brep geometry in PoseParts)
    {
        if (geometry.IsValid)
        {
            DefaultMaterial.Diffuse = (System.Drawing.Color)geometry.UserDictionary["color"];
            if (gvp.DisplayMode.EnglishName == "Wireframe")
            {
                display.DrawBrepWires(geometry, DefaultMaterial.Diffuse);
            }
            else
            {
                display.DrawBrepShaded(geometry, DefaultMaterial);
            }
        }
    }
}

This is probably the biggest (IE slowest) method in my display conduit. The inside loops probably contain about a thousand meshes. But it does work a lot of the time…just not all the time.

If I may hazard a guess, you access the UserDictionary of the geometries very often to read their color (each frame redraw, for each viewport), and I have experienced problems with this; in our case if we have thousands of objects and access their UserDictionary very fast (i.e. in a loop), we also experience spurious crashes or AccessViolationException.

A possible solution would be to cache the color for each part, such that you don’t need to lookup the color so often. You can simply do this in a Dictionary<GeometryBase,Color> lookup you create once for the geometries (for example, in the constructor of the display conduit), and then read the color back from this. Of course, this assumes that the color stays constant during the lifetime of the display conduit.

Thanks for the idea, I will think about this for sure. The color does not stay constant(my conduit lives a very long time, maybe that is also a concern? IE it is for the life of the command that launches the GUI…which is normally not closed again once launched). In an earlier versions I stored color as a property of the AxisGeometry object; I changed it to UserDictionary about a year ago thinking this was lighter/better. The color changes often but not nearly as often as the display conduit events are fired. One of my reasons to move to UserDictionary was the potential to serialize the state of the plugin. I haven’t looked into this recently(not in C# either) but presumably I can do it just as easily if I try to serialize the AxisGeometry. In python we used pickle and it worked well…

Thanks, I will refactor the color and see where that goes…

Old Thread, but apparently this type of error doesn’t happen much. I am getting an AccessViolationException when using Brep.CreateFromSweep. The error is intermittent, meaning I can slightly change my script parameters and it will not occur. What seems to be consistent is that it only occurs when I am calling the method inside of a Parallel.For loop. Many times it works, just not always. It seems that the longer the calculation time (which causes more threads I guess) the more likely the error.

Any issues using Brep.CreateFromSweep multi-threaded? It certainly helps with the speed, but crashing is no fun.

Hmm, after correcting what would seem to be an unrelated bug in my script, this problem seems to go away. It doesn’t explain why the error was only occurring when using Parallel.For , but I guess its a lucky break…

I doubt Brep.CreateFromSweep is thread safe. Make sure you don’t use the same curve(s) in each thread.

– Dale

1 Like

Thanks,
I am pretty sure I am not using the same curves. If it pops up again I will check that.