[Pkg-octave-devel] Bug#480431: Bug#480431: Bug#480431: Bug#480431: octaviz: Segfault on AMD64
thomas.weber.mail at gmail.com
Fri Sep 5 19:57:13 UTC 2008
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
> 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
Well, VTK doesn't support NaNs, at least according to
So, my "solution" would be: patch vtk_surf() to check for NaN and error out if it
More information about the Pkg-octave-devel