[vtkusers] ActiViz 5.8.0 recurring random AccessViolationException

Steve M. Robbins steve at sumost.ca
Thu Jun 25 19:30:09 EDT 2015


On Mon, Jun 01, 2015 at 08:39:24AM -0500, Steve M. Robbins wrote:
> On June 1, 2015 05:35:01 AM Christophe DUPERTHUY wrote:
> 
> 
> > There seemed to be a latent concern on the way objects were de-allocated in
> > the C# wrapping within a multi-threaded application.
> 
> I'm having similar trouble with a C# application using mummy-wrapped VTK 5.8.
> [...]
> It turns 
> out that simply using VtkActor.GetProperty() [the actor is a vtkOpenGLActor] 
> is enough to cause the crash -- even if I don't actually use the property to 
> change the colour or anything else.  So the problem appears to be triggered by 
> creating and destroying a large number of C# VtkProperty objects.

Running Christophe's reproduction code [1] under the debugger, I can see the
access violation consistently happens in the ** line of this function:


       void vtkInformation::ReportReferences(vtkGarbageCollector* collector)
       {
		this->Superclass::ReportReferences(collector);
    		// Ask each key/value pair to report any references it holds.
      		typedef vtkInformationInternals::MapType MapType;
        	for(MapType::const_iterator i = this->Internal->Map.begin();
	 	    i != this->Internal->Map.end(); ++i)
	        {
**			i->first->Report(this, collector);
		}
	}


This happens in the GC Finalizer thread, presumaably because there is a race
between registration and un-registration and the map changes while iterating
through.  

Guessing that my code has a similar race, I fixed the issue by simply
caching the ActiViz objects for the lifetime of the underlying VTK
objects.  This avoids the reference-counting race and appears to work
OK.  But I have to do so for each object, which is error-prone.

Christophe alludes to this being fixed in VTK 6.2 [2].  So naturally,
I'm curious how this was achieved in the general case.  Can Kitware
comment?

Thanks,
-Steve

 [1] http://public.kitware.com/pipermail/vtkusers/2014-September/085071.html
 [2] http://public.kitware.com/pipermail/vtkusers/2015-June/091018.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: Digital signature
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20150625/c8d8ba61/attachment.sig>


More information about the vtkusers mailing list