[Octave-bug-tracker] [bug #65431] crash after hgload certain data

[Nicholas Jankowski]

Follow-up Comment #19, bug #65431 (group octave):

ok, after comparing matlab and the different octave datasets (really need a
minimal crash example), it appears supplying cdata with Faces/Vertices
geometry corrupts the Vertices data.

in matlab:
when creating a patch with Faces/Vertices/FaceVertexCData, and supplying
FVCData with 1 column x n vertices of data, the patch object is populated with
consistent xdata, ydata, zdata, and CData.  size of those is 1 column per
face, each element in each column is a point.  vertices/faces/fvcdata match
what was input.

when creating a patch with Faces/Vertices/CData, and supplying CData with 1
column x n vertices of data (not a proper format but no error), the patch
object is still populated with the same, consistent x/y/zdata __and__ CData as
in the previous case, _not_ the data that the user supplied.  FVCData contains
the color data supplied, and CData is altered to be consistent. 

also, on input validation: if facecolor is interp, then fvcd must be scalar or
be Nx1 where N = rows (Vertices). if facecolor is flat, then fvcd must match
the number of vertices or faces, error otherwise.

In Octave:

when creating a patch with Faces/Vertices/FaceVertexCData, and supplying
FVCData with 1 column x n vertices of data,  the patch object is also
populated with consistent xdata, ydata, zdata, and CData and 
vertices/faces/fvcdata match what was input.

when creating a patch with Faces/Vertices/CData, and supplying _CData_ with 1
column x n vertices of data, the patch object is still populated with the
same, consistent x/y/zdata, but CData contains the supplied data, as does
FVCData.  faces matches the input.  *_vertices for some reason is 3x the size
of the number of faces (10758x3 instead of 1837x3)_*

so, whatever part of the creation algorithm is doing that, it's doing it
wrong. based on the number that must be what @jwe found with it indexing fvc
from 0:10757.    his patch stops it from iterating past the number of fvc
rows.

on validation, unpatched Octave seems perfectly happy letting you set FVCD
with any number of rows, when it should error if not 1, nfaces, or nvertices. 
markus's patch appears to do that input validation. 

I can only get the crash to happen when rotating the image.  I don't know what
goes on under the hood, but i guess it calls the patch::update_data function. 
(why? nothings changes in the patch object with a view change does it?)  then
it iterates through fvc thinking there are 10000 rows, and there aren't.
_crash_.


So, why does patch creation with CData corrupt Vertices?  I'm learning but i'm
pretty terrible at trying to jump around graphics.cc from function to function
to step through the creation process flow.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65431>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/