[Pkg-octave-devel] Bug#480431: Bug#480431: Bug#480431: Bug#480431: octaviz: Segfault on AMD64

[Thomas Weber]

On Fri, Sep 05, 2008 at 01:15:07PM +0200, Rafael Laboissiere wrote:
> * Thomas Weber <thomas.weber.mail at gmail.com> [2008-06-09 09:11]:
> 
> > Am Samstag, den 10.05.2008, 07:33 +0200 schrieb Thomas Weber:
> > > On 09/05/08 18:34 -0500, Jordi Gutiérrez Hermoso wrote:
> > > > Package: octaviz
> > > > Version: 0.4.7-1
> > > > Severity: important
> > > > 
> > > > With the attached script and data, Octaviz segfaults on AMD64.
> > > 
> > > As I discussed with Jordi earlier: this is arch-specific, it doesn't
> > > happen on i386.
> > 
> > I've tracked this back till line 271 of vtkClipPolyData.cxx, where
> > 	cellScalars->GetComponent(1,0)
> > is a NaN value. 
> 
> Should this bug be considered release-critical, as it is now (severity level
> "serious")?  The octaviz package is essentially functional and the problem
> reported happens in the vtk_surf function (well, maybe also in others, who
> knows...)

> 
> Anyway, I think that it is too harsh to drop octaviz from lenny only because
> of that.  I would prefer to downgrade the severity to "important" and, as an
> interim solution, upload a new version of octaviz with a patched vtk_surf
> file.  For instance, we could change the doc string by alerting the user
> about NaN or, better, return an error message if the input Z matrix contains
> NaN values.  At any rate, the user can circumvent this bug by changing her
> script (see the modified plotresults_vtk.m attached below).
> 
> What do you think?

Aarrgg, Rafael, you are my hero. 

Up until now, I thought that there was a bug in Octaviz/VTK, that
created these NaN values. Now I see that they are coming from
griddata().

Well, VTK doesn't support NaNs, at least according to 
http://www.vtk.org/pipermail/vtk-developers/2007-January/004421.html
http://thread.gmane.org/gmane.comp.science.electromagnetism.meep.general/295

So, my "solution" would be: patch vtk_surf() to check for NaN and error out if it
finds them.

	Thomas