octaviz-help

Re: [Octaviz-help] More on the Octaviz segfault

[Jonathan S. <jjs...@vc...>]

Jordi Gutiérrez Hermoso wrote:
> Hello, Jonathan and Thomas
> 
> Alright, I think I'm getting an idea of what could be wrong. The
> parser that wraps the VTK classes for Octave needs to be fixed for
> 64bit types.
> 
> The most glaring problem I can see, at least against the cvs version
> of VTK, is that the parser is assuming (in Wrapping/vtkParse.l) that
> vtkIdType is an int, while it looks like in 64bit builds vtkIdType is
> actually typedeffed to a long long int. This produced a compile error
> with the cvs VTK, and my guess is that this error was only caught
> later at runtime with the version of VTK in Debian. I haven't looked
> exactly at this latter version, but if Octaviz is somehow giving int*
> when VTK expects long long*, well, that would definitely be a
> segfault.
> 
> The cvs VTK provides better Wrapping/vtkParse.* files for Flex and
> Bison which have the right 64bit types in them, but using them with
> Octaviz requires modifying Octaviz's Wrapping/vtkWrapOctave.c
> 
> I'll keep working on this...
> 
> - Jordi G. H.
> 
> 

Thank you for your efforts here.  I would prefer that octaviz continues 
to work with the latest official release of VTK.  For awhile octaviz was 
programmed against VTK-cvs, which made it very difficult to make a 
release since VTK was long delayed in releasing 5.0.

Jonathan

Re: [Octaviz-help] More on the Octaviz segfault

[J. G. H. <jo...@gm...>]

On 12/05/2008, Jonathan Stickel <jjs...@vc...> wrote:
> Jordi Gutiérrez Hermoso wrote:
> > The most glaring problem I can see, at least against the cvs version
> > of VTK, is that the parser is assuming (in Wrapping/vtkParse.l) that
> > vtkIdType is an int, while it looks like in 64bit builds vtkIdType is
> > actually typedeffed to a long long int.
>
> I would prefer that octaviz continues to work with the latest official
> release of VTK.

Alright, I guess that makes sense. I don't get a compile time error
when building against the latest VTK release, but there still is a
problem of Octaviz assuming that vtkIdType is an int on a 64bit
system.

I guess you can say that the cvs build of VTK at least pointed out
what a likely problem could be.

- Jordi G. H.

Re: [Octaviz-help] More on the Octaviz segfault

[Thomas W. <tho...@gm...>]

Am Montag, den 12.05.2008, 08:43 -0500 schrieb Jordi Gutiérrez Hermoso:
> On 12/05/2008, Jonathan Stickel <jjs...@vc...> wrote:
> > Jordi Gutiérrez Hermoso wrote:
> > > The most glaring problem I can see, at least against the cvs version
> > > of VTK, is that the parser is assuming (in Wrapping/vtkParse.l) that
> > > vtkIdType is an int, while it looks like in 64bit builds vtkIdType is
> > > actually typedeffed to a long long int.
> >
> > I would prefer that octaviz continues to work with the latest official
> > release of VTK.
> 
> Alright, I guess that makes sense. I don't get a compile time error
> when building against the latest VTK release, but there still is a
> problem of Octaviz assuming that vtkIdType is an int on a 64bit
> system.

I looked into this and I think vtkIdType being int is actually correct,
unless you set VTK_USE_64BIT_IDS (which seems to be unset by default).

	Thomas

Re: [Octaviz-help] More on the Octaviz segfault

[J. G. H. <jo...@gm...>]

On 30/05/2008, Thomas Weber <tho...@gm...> wrote:
> I looked into this and I think vtkIdType being int is actually correct,
>  unless you set VTK_USE_64BIT_IDS (which seems to be unset by default).

It may work in some cases, but it didn't even compile against the cvs
VTK. The politically correct action would be to set it to IdType in
the parser and to let VTK itself decide if that should be an int or
not. My suspicion is still that the Octaviz parser is producing code
that is working most of the time but that some obscure undocumented
feature or bug of the VTK shipped with Debian let it slip by during
compilation.

This involves making quite a few modifications to the Octaviz parser,
in order to make it work with later versions of the VTK bison and flex
grammar files. I haven't worked on this for the past couple of weeks,
and the next few weeks involve preparing finals for my students and
lots of bureaucracy. I still plan, however, to dust off my
undergraduate notes on parsers and context free grammars and see how I
can synch Octaviz's parser with the better 64-bit aware grammar. ;-)

Of course, I have been slow in the past complying with this sort of
thing, so feel free to do it yourself if you get impatient with me.

- Jordi G. H.

Re: [Octaviz-help] More on the Octaviz segfault

[Thomas W. <tho...@gm...>]

Am Freitag, den 30.05.2008, 08:29 -0500 schrieb Jordi Gutiérrez Hermoso:
> On 30/05/2008, Thomas Weber <tho...@gm...> wrote:
> > I looked into this and I think vtkIdType being int is actually correct,
> >  unless you set VTK_USE_64BIT_IDS (which seems to be unset by default).
> 
> It may work in some cases, but it didn't even compile against the cvs
> VTK. The politically correct action would be to set it to IdType in
> the parser and to let VTK itself decide if that should be an int or
> not. My suspicion is still that the Octaviz parser is producing code
> that is working most of the time but that some obscure undocumented
> feature or bug of the VTK shipped with Debian let it slip by during
> compilation.

I don't think th vtkIdType is really the problem. If my gdb skills are
sufficient[1], then InsertUniquePoint() is called from vtkTriangle with
a vector x of three elements, all of which are NaN.

I don't think that should happen. 

[1] They are quite limited.


> This involves making quite a few modifications to the Octaviz parser,
> in order to make it work with later versions of the VTK bison and flex
> grammar files. I haven't worked on this for the past couple of weeks,
> and the next few weeks involve preparing finals for my students and
> lots of bureaucracy. I still plan, however, to dust off my
> undergraduate notes on parsers and context free grammars and see how I
> can synch Octaviz's parser with the better 64-bit aware grammar. ;-)

Eh, I know basically no C++ and have zero knowledge about parsers and
lexers. Be my guest :)

	Thomas

Re: [Octaviz-help] More on the Octaviz segfault

[J. G. H. <jo...@gm...>]

On 30/05/2008, Thomas Weber <tho...@gm...> wrote:
> Am Freitag, den 30.05.2008, 08:29 -0500 schrieb Jordi Gutiérrez Hermoso:
>
> > My suspicion is still that the Octaviz parser is producing code
>  > that is working most of the time but that some obscure undocumented
>  > feature or bug of the VTK shipped with Debian let it slip by during
>  > compilation.
>
>
> I don't think th vtkIdType is really the problem. If my gdb skills are
>  sufficient[1], then InsertUniquePoint() is called from vtkTriangle with
>  a vector x of three elements, all of which are NaN.

Yeah, I saw that too, but I don't *think* that should cause a
segfault. When you pass other NaN's to Octaviz, you just get blank
plots, not segfaults. Ah, well. I guess we're still guessing until I
see if fixing the parser makes the segfault go away or not.

- Jordi G. H.