Hallo @ll,

we are using VTK (Version: as Graphic API and have problems with a System.AccessViolationException : Attempt to read or write protected memory, which keeps occurring randomly, sometimes after 30 minutes or after 4 hours.
I really don’t know how to work around this problem anymore.

The exception producing code is actually nothing special. The error occurs when we populate, or pass, a glyph with a source connection, which can be either an arrow or a sphere.
glyph.SetSourceConnection(graphObj); // Line of Exception

At the given point it throws an exception, the vtkPolyData are filled with vtkPoints, but we have already checked them for validity. However, I don’t think this is our problem. The function we are using looks like this. Also, the way the Actor or PolyData is passed to the function doesn’t seem to matter (copy, ref, in: unimportant)


 private void InitPolyData(
         ref vtkPolyData polyData,
         ref vtkPoints points,
         in string colorName,
         in vtkAbstractArray colorArray,
         in string velocityName,
         in vtkAbstractArray velocityArray
         this.InitPolyData(ref polyData, ref points, colorName, colorArray);

         // Add Velocity Array (points) to polydata
 private void InitActor(
         ref vtkActor actor,
         in bool isArrow,
         ref vtkPolyData inputData,
         in bool extendedArgs
         vtkGlyph3D glyph = new vtkGlyph3D();
         vtkPolyDataMapper mapperMoving = new vtkPolyDataMapper();
         vtkAppendPolyData polyDataListMoving = new vtkAppendPolyData();

         vtkAlgorithmOutput graphObj;
         if (isArrow)
            /* Create Arrow geometry (sounds more complicated than it is :D) */
            vtkArrowSource arrowSource = new vtkArrowSource();
            graphObj = arrowSource.GetOutputPort();
            // Sphere for stationary points
            vtkSphereSource sphereSource = new vtkSphereSource();
            graphObj = sphereSource.GetOutputPort();


         /* Create Actor for point cloud and add mapper */

         // actor = new vtkActor();

         /* Set point size */

         if (extendedArgs)




Maybe someone knows this kind of error.

Thank you and best regards

Are you monitoring application memory usage ? If I had to make a bet, there is a memory leak somewhere…

That was actually one of my first approaches, but a memory leak, has not been confirmed, if one exists, this is not something that is noticeable by profiling. It also doesn’t matter if you render 200 or 4000 points. The memory behavior does not change.
We don’t use unsaved code in C#, so that doesn’t rule out memory leaks, but it makes them less likely.
However, Access Violation is more likely to indicate uninitialized code, or perhaps even memory access that the program is not allowed. What exactly happens in the C++ code of VTK I cannot estimate, but it may not happen in the C# wrapper.
I absolutely don’t know.

Cc: @mwestphal @jfausty (not sure who to contact for VTK/C# support)

@LucasGandel might be interested by this

1 Like

Similar issues are sometimes caused by the GC deleting VTK objects while the unmanaged code still references the collected object.
I’ve only experienced this when using event handlers, but maybe vtkGlyph3D has similar issues.
If you confirm that glyph.SetSourceConnection(graphObj); triggers the exception, can you try storing both glyph and graphObj as members in your class?
This should increase the lifetime of those objects and prevent the GC from collecting them.

Note: The fact that the issues appears after some time probably confirms that the GC is involved.

I missed this one, please tag me for C# related questions. Thanks

For now, we just catch the bug and at least we don’t have any obvious problems as a result (In the long run, maybe we do) . I’ll try your approach and then report back if catching the object does anything. (But I think I have already tried this approach).
My guess is that the garbage collector is throwing away something that is actually still needed.
The reference count doesn’t seem to be really deterministic here either, although I would expect that.

My guess is that the garbage collector is throwing away something that is actually still needed.

I agree. Identifying that object would help us fixing the problem in Activiz. Storing it in a class is a valid workaround in the meantime.
I’ll try to reproduce in a small example and will update here if I find anything.