[Fwd: Re: [vtkusers] Bug with Shallow Copy and Deconstructors]

[Berk Geveci]

-----Forwarded Message-----

> From: Berk Geveci <berk.geveci at kitware.com>
> To: Brad Lowekamp <blowek1 at csee.umbc.edu>
> Subject: Re: [vtkusers] Bug with Shallow Copy and Deconstructors
> Date: 27 Jun 2002 08:13:14 -0400
> 
> This bug has already been fixed. However, the fix is not
> in 4.0. You will have to either wait for the next release
> or download a nightly distribution.
> 
> -Berk
>   
> On Thu, 2002-06-27 at 00:13, Brad Lowekamp wrote:
> > The way that this bug has manifested itself to me is by the field data
> > disappearing during filters operating on it. I have encountered a similar
> > bug with the vtkDataObjectToDataSetFilter and posted about it. I have also
> > encountered similar problems with several other classes. If two data
> > objects share an object lets say from a shallow copy, and one of the data
> > objects is deleted the data is deleted in the other. I have frequently
> > encountered this with the field data. I have spent a significant amount of
> > time tracking down and understanding all the related code. This bug can be
> > easily seen in the following tcl code, when the source contains field
> > data.
> > 
> > vtkPolyDataReader reader
> > reader SetFileName test.vtk
> > 
> > vtkPolyData pd
> > pd ShallowCopy [reader GetOutput]
> > 
> > puts [[pd GetFieldData] GetNumberOffArrays]
> > 
> > reader Delete
> > 
> > puts [[reader GetFieldData] GetNumberOfArrays]
> > 
> > Have other people encountered their data disappearing too? I have searched
> > that archive and not found much. I can't image that I am the only one. To
> > me this type of bug seems very significant and that other people must have
> > encountered it before. Or do few people delete their classes before they
> > are finished?
> > 
> > The project that I have been working on involves using the fielddata in
> > vtkDataObject and dynamically creating and deleting vtk objects. As a
> > result I have had to create an abstract filter vtkDataObjectToDataObject
> > to do a lot of transformation. And I have needed to keep careful track of
> > Objects, making sure they get deleted and filters remain correct when the
> > input and outputs are changed. In working with this I have had much
> > frustration working with VTK. Because it seems as though neither of these
> > aspects of VTK have been tested or worked with much before. It is
> > infrequent when there is a task that I wish to get done where the filters
> > are neither designed to work with vtkDataObject nor handle the FieldData
> > in a vtkDataSet correctly.
> > 
> > For example I was working with the vtkSourcePort and vtkInputPort and
> > trying to transmit FieldData with it. It does not accept vtkDataObject as
> > a class to transmit. No problem, I will just add a dumpy point and send a
> > vtkPolyData across the network. But wait the field data mysteriously
> > disappears! After a day of searching, I have come to discover that the
> > vtkDataSetReader uses SHALLOWCOPY. Which can be traced to the source of
> > the disappearing data! I dont see how vtkDataSetReader can read FieldData!
> > (Try using vtkDataSetReader instead of vtkPolyData in the above example,
> > interesting!)
> > 
> > I have seen this bug occour in many other filters as well. ANY filter
> > which uses a ShallowCopy will likely have this same bug too! Perhaps
> > people have not encountered this bug more because few people use the
> > FieldData and still fewer realize what is sometime goes on is a bug. It is
> > wide spread and shows itself is many different places, but there us just a
> > few places that need modification to fix it and those are with the
> > interaction with the deconstructors and initialization function of
> > DataObjects and related classes.
> > 
> > There is a simple rule that should be adopted by deconstruction that would
> > work and solve this problem so that shallow copies can be used with out
> > fear of causing bugs! The rule is: For every vtkObject an objects owns
> > (has a registered pointer to) Unregister or Delete it, and then set the
> > variable to NULL, but DO NOT CALL THAT VTKOBJECTS INITIALIZATION function.
> > 
> > 
> > To get my project to work, I must fix this bug myself in vtkDataObject. I
> > don't know how people submit code, but certainly I think that this is a
> > good candidate for that. However because these fixes are so close to the
> > core and could affect most of the other classes I am sure there many
> > issues. I certainly hope that this issue well be addressed. And I am
> > willing to give my help to getting it fixed.
> > 
> > 
> > _______________________________________________
> > This is the private VTK discussion list. 
> > Please keep messages on-topic. Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtkusers
>