[Insight-developers] RE: ReleaseDataFlagOn() and some minipipeline filters. Seg.Fault .

[Miller, James V (Research)]

In the case of mini-pipelines, the first node in the mini-pipeline should
not set ReleaseDataOn().  The input to the first node in the mini-pipeline
will be handled by the standard pipeline mechanism when the "outer" filter
executes.  The filter writer can turn ReleaseDataOn() on filters 2-N of
their mini-pipeline without concern for the "outer" filter and the rest of
the pipeline.

Jim

> -----Original Message-----
> From: Luis Ibanez [mailto:luis . ibanez at kitware . com]
> Sent: Sunday, August 31, 2003 11:29 AM
> To: Brad King
> Cc: insight-dev-list; Miller, James V (Research); Joshua Cates
> Subject: ReleaseDataFlagOn() and some minipipeline filters. Seg.Fault.
> 
> 
> 
> Hi,
> 
> Tracking a crash on one of the volview plugins I found that some
> filters do not allow to call ReleaseDataFlagOn() on their immediate
> predecessors on the pipeline.
> 
> Filters like the AntiAliasImageFilter, which derives from the
> itkSparseFieldLevelSetImageFilter, have internal filters that
> call "Update()" as part of their internal processing.  When
> this internal Update() call is issued, the predecessor filter
> will release its output data (if the ReleaseDataFlag is on),
> making that any subsequent access to the input image in the
> SparseFieldLevelSetImageFilter will result in invalid memory
> access.
> 
> At this point of the release process,  it only seems to be worth
> to log this as an issue in GNATS, and probably add Doxygen
> warning/comments in the filters having internal pipelines.
> 
> On the long run, these filters could Check if their predecessors
> have ReleseaDataFlagOn(), and disable it until the total filter
> is executed (not only part of its internal pipeline).
> 
> 
>    Luis
> 
> 
>