Unfortunately, I dont have access to a 64bit machine to test octaviz myself. All I can do to help you out is to propose solutions but youll have to test them yourself.
You probably found one source of the problem yourself: casting ints into pointers. This is unavoidable since the pointers have to pass through octave as variables. The problem is whether unsigned int both in octave and in C++ is actually 64 bits. Could you please tell me what c++ says for sizeof(unsigned int)? If it gives 64 bits, then the problem is the size of unisgned int in octave. If it doesnt then unsigned int needs to be changed to another 64 bit integer everywhere in octaviz.h and in VTK wrapper.
Ill check the octave part later today and Ill let you know if I find a way to solve the problem. I would appreciate greatly if you help me debug this so I can fix octaviz for 64 bit architectures.
Cheers,
Dragan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the pointer and sizeof info! I'll change all unsigned ints in octaviz to uintptr_t. The remaining problem is octave's internal representation of integers so it might take an iteration or two before everything falls in place. As soon as I fix the sources I'll send them to you.
Cheers,
Dragan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here are some more information about the problems running octaviz on a 64 bit machine.
The compiler itself has detected some problematic codes. For instanse it produced the following error while compiling octaviz:
vtkInitializeInteractor.cc: In function `octave_value_list
FvtkInitializeInteractor(const octave_value_list&, int)':
vtkInitializeInteractor.cc:79: error: reinterpret_cast from `
vtkXOpenGLRenderWindow*' to `unsigned int' loses precision
I changed some "unsigned int" to 'uintptr_t' in various places of octaviz.cc and vtkInitializeInteractor.cc. Here are the diffs:
This pointer address 0x1070050 is suspicious. It seems that the 64 bit pointer is truncated to 32 bit, since normaly the pointer addresses in 64 bit are longer.
Cheers,
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the info! You solved most of the problem. (I hope) the only remaing problem to fix is in vtkWrapOctave.c. There are three lines where reinterpret_cast appears in that file. You should change
uint_value()
to
uint64_scalar_value().value()
in those three lines. I hope it'll work afterwards.
Cheers,
Dragan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, octave-2.1.57 does not have 'uint64_scalar_value'. I will try to build octave-2.1.64.
I have had some strange problems with the 2.1.57 version with other packages (I needed to compile oct file with -g), so I hope I will have less problems with the latest octave version.
Cheers,
Alexander
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made the changes in vtkWrapOctave.c and I recompiled all octaviz for octave 2.1.64. There is a problem with uint64_scalar_value. My wild guess would be that octave does not know how to convert a vtl_object to a uint64_scalar_value. A missing constructor?
Cheers
Alex
octave:1> vtk_init;
octave:2> cone = vtkConeSource();
octave:3> cone.SetHeight( 3.0 );
error: octave_base_value::uint64_scalar_value(): wrong type argument `vtk_object'
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
error: octave_base_value::save_binary(): wrong type argument `vtk_object'
save to `octave-core' complete
Segmentation fault (core dumped)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Octave shouldn't be constructing anything since it only returns scalar value that is casted into a pointer by reinterpret_cast. Could you send me please the three lines that you changed?
Thanks,
Dragan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please help me. I'm trying to use octaviz on Mandrake linux version 9.1 with the following set of packages, octave-2.1.67 ,VTK-4.4 (-LatestRelease.tar.gz) and octaviz-0.4.0. I've installed these packages by following the steps outlined in the respective readme or install files. Both the vtk and octave seem to work when I test them independently (..i.e I try the vtk examples both tcl and python files..,and I also test some functions in the octave m-files). Whenever I try the vtk .oct and m-files, I get " panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'..." response immedeately...
When I use gdb and run the hello file, I get the following report..
octave:1> hello
[New Thread 16384 (LWP 15859)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 15859)]
octave_user_function::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (this=0x1068,
type=@0x40108682, idx=@0x40108692, nargout=1074824866)
at /usr/include/c++/3.2.2/bits/stl_list.h:126
126 : _List_iterator_base(__x)
Current language: auto; currently c++
(gdb)
Any help is welcome..
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Most likely you haven't installed vtk data (you can fetch it from vtk.org) which is required by some examples. To avoid this could you please try something more simple like
vtk_plot3( rand(10,1), rand(10,1), rand(10,1) );
an let me know what happend.
Cheers,
Dragan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do have the vktdata installed under the vtk root directory.. when I try the vtk plot as you suggested, I still got but the seg. fault error but a shorter one ....
I'll need a bit more info before I can help you. In particular I need to know what version of g++ are you using and please send me CMakeCache.txt from octaviz root directory.
Thanks,
Dragan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had also some spurious errors when I used the precompiled Octave from Fedora. These problems disappeared when I compiled myself octave, VTK and octaviz. This might be due to different compiler versions or options.
Cheers
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Octave users and developpers,
I use the following versions:
octave-2.1.57
VTK-4.4 (-LatestRelease.tar.gz)
octaviz-0.4.0
I tried to build octaviz in 64 bit mode on my 64 bit AMD machine. But even after replacing some
unsigned int key = reinterpret_cast<unsigned int>( pointer );
by
uintptr_t key = reinterpret_cast<uintptr_t>( pointer );
in octaviz.cc, octave crashed when calling a octaviz-routine. The pointer casting is perhaps something that would be anyway usefull to fix.
I restarted with all components in 32 bit. However, octave did not find the VTK routines. I obtained the following error after:
$ export LD_ASSUME_KERNEL=2.4.1
# add VTK to search path
$ export
LD_LIBRARY_PATH="/home/abarth/local/lib/vtk/:$LD_LIBRARY_PATH"
$ octave
octave:1> vtkTextActor('help')
error: /usr/libexec/octave/2.1.57/site/oct/i686-pc-linux-gnu/octaviz/vtkTextActor.oct: undefined symbol: _ZN10vtkActor2D16CollectRevisionsERSo
error: `vtkTextActor' undefined near line 1 column 1
But this function ( vtkActor2D::CollectRevisions(std::basic_ostream<char, std::char_traits<char> >&)) is well defined in vtkCommon.so:
$ nm /home/abarth/local/lib/vtk/libvtkCommon.so | fgrep _ZN10vtkActor2D16CollectRevisionsERSo
00000000000ae774 t _GLOBAL__I__ZN10vtkActor2D16CollectRevisionsERSo
00000000000ac8b8 T _ZN10vtkActor2D16CollectRevisionsERSo
I have also added the VTK library to /etc/ld.so.conf, but without any effect.
Any help would be greatly apreciated.
Thanks
Alexander
Hi Alexander,
Unfortunately, I dont have access to a 64bit machine to test octaviz myself. All I can do to help you out is to propose solutions but youll have to test them yourself.
You probably found one source of the problem yourself: casting ints into pointers. This is unavoidable since the pointers have to pass through octave as variables. The problem is whether unsigned int both in octave and in C++ is actually 64 bits. Could you please tell me what c++ says for sizeof(unsigned int)? If it gives 64 bits, then the problem is the size of unisgned int in octave. If it doesnt then unsigned int needs to be changed to another 64 bit integer everywhere in octaviz.h and in VTK wrapper.
Ill check the octave part later today and Ill let you know if I find a way to solve the problem. I would appreciate greatly if you help me debug this so I can fix octaviz for 64 bit architectures.
Cheers,
Dragan
Hi Dragan,
I found this page about making program "64 bit proof':
http://developers.sun.com/solaris/articles/solarisupgrade/64bit/Convert.html
The data type uintptr_t works on 32 and 64 bit machines for pointer casting. I wrote a small program testint.cc:
#include <iostream.h>
#include <inttypes.h> // for uintptr_t
int main() {
cout << "sizeof(void*) " << sizeof(void*) << endl;
cout << "sizeof(unsigned int) " << sizeof(unsigned int) << endl;
cout << "sizeof(uintptr_t) " << sizeof(uintptr_t) << endl;
return 0;
}
Which gave the following output:
$ g++ testint.cc
$ ./a.out
sizeof(void*) 8
sizeof(unsigned int) 4
sizeof(uintptr_t) 8
In 32 bit emulation mode, I obtain:
$ g++ -m32 testint.cc
$ ./a.out
sizeof(void*) 4
sizeof(unsigned int) 4
sizeof(uintptr_t) 4
Thus the size of a pointer is always equal to the size of uintptr_t.
I hope this helps
Cheers
Alex
Hi Alex,
Thanks for the pointer and sizeof info! I'll change all unsigned ints in octaviz to uintptr_t. The remaining problem is octave's internal representation of integers so it might take an iteration or two before everything falls in place. As soon as I fix the sources I'll send them to you.
Cheers,
Dragan
Hello Dragan,
Here are some more information about the problems running octaviz on a 64 bit machine.
The compiler itself has detected some problematic codes. For instanse it produced the following error while compiling octaviz:
vtkInitializeInteractor.cc: In function `octave_value_list
FvtkInitializeInteractor(const octave_value_list&, int)':
vtkInitializeInteractor.cc:79: error: reinterpret_cast from `
vtkXOpenGLRenderWindow*' to `unsigned int' loses precision
I changed some "unsigned int" to 'uintptr_t' in various places of octaviz.cc and vtkInitializeInteractor.cc. Here are the diffs:
$ diff octaviz.cc octaviz.cc.orig
45,46d44
< #include <inttypes.h> // for uintptr_t
<
119c117
< uintptr_t key = reinterpret_cast<uintptr_t>( pointer );
---
> unsigned int key = reinterpret_cast<unsigned int>( pointer );
154c152
< uintptr_t key = reinterpret_cast<uintptr_t>( vtk_pointer );
---
> unsigned int key = reinterpret_cast<unsigned int>( vtk_pointer );
167c165
< uintptr_t key = reinterpret_cast<uintptr_t>( vtk_pointer );
---
> unsigned int key = reinterpret_cast<unsigned int>( vtk_pointer );
185c183
< return reinterpret_cast<uintptr_t>(vtk_pointer);
---
> return reinterpret_cast<unsigned int>(vtk_pointer);
$ diff vtkInitializeInteractor.cc vtkInitializeInteractor.cc.orig
27d26
< #include <inttypes.h>
80c79
< vtk_delete_window_atoms[wm_delete_window] = reinterpret_cast<uintptr_t>(RenderWindow);
---
> vtk_delete_window_atoms[wm_delete_window] = reinterpret_cast<unsigned int>(RenderWindow);
With these changes octaviz compiles, but there are probably more pointer problems. If I try octaviz, I get the following error:
octave-2.1.57:1> vtk_init;
free(): invalid pointer 0x1070050!
octave-2.1.57:2> Cone;
panic: Segmentation fault -- stopping myself...
This pointer address 0x1070050 is suspicious. It seems that the 64 bit pointer is truncated to 32 bit, since normaly the pointer addresses in 64 bit are longer.
Cheers,
Alex
Thanks for the info! You solved most of the problem. (I hope) the only remaing problem to fix is in vtkWrapOctave.c. There are three lines where reinterpret_cast appears in that file. You should change
uint_value()
to
uint64_scalar_value().value()
in those three lines. I hope it'll work afterwards.
Cheers,
Dragan
Unfortunately, octave-2.1.57 does not have 'uint64_scalar_value'. I will try to build octave-2.1.64.
I have had some strange problems with the 2.1.57 version with other packages (I needed to compile oct file with -g), so I hope I will have less problems with the latest octave version.
Cheers,
Alexander
Hello Dragan,
I made the changes in vtkWrapOctave.c and I recompiled all octaviz for octave 2.1.64. There is a problem with uint64_scalar_value. My wild guess would be that octave does not know how to convert a vtl_object to a uint64_scalar_value. A missing constructor?
Cheers
Alex
octave:1> vtk_init;
octave:2> cone = vtkConeSource();
octave:3> cone.SetHeight( 3.0 );
error: octave_base_value::uint64_scalar_value(): wrong type argument `vtk_object'
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
error: octave_base_value::save_binary(): wrong type argument `vtk_object'
save to `octave-core' complete
Segmentation fault (core dumped)
Hi Alex,
Octave shouldn't be constructing anything since it only returns scalar value that is casted into a pointer by reinterpret_cast. Could you send me please the three lines that you changed?
Thanks,
Dragan
Hi Dragan,
Here are the 3 changed lines:
fprintf(fp," else temp%i = reinterpret_cast<%s*>( args(%i).uint64_scalar_value().value() );\n",i,currentFunction->ArgClasses[i],start_arg);
fprintf(fp," %s *vtk_pointer = reinterpret_cast<%s*>( args(0).uint64_scalar_value().value() );\n",data->ClassName,data->ClassName);
fprintf(fp," vtk_object *vtk_obj = reinterpret_cast<vtk_object*>( args(0).uint64_scalar_value().value() );\n");
Cheers
Alex
Hi Alex,
OK, add this in octaviz.h in public section of vtk_object declaration
octave_uint64 uint64_scalar_value (void) const;
and this in octaviz.cc
octave_uint64 vtk_object::uint64_scalar_value (void) const
{
return reinterpret_cast<octave_uint64_t>(vtk_pointer);
}
This should fix the problem.
Happy holidays,
Dragan
Hi Dragan,
It works now ! Thank you very mush for your help. Octaviz is great !
While testing octatiz, I have found a bug in the plotting routines: vtk_contour3.m, vtk_meshc.m, vtk_mesh.m and vtk_surf.m.
The line in these scripts:
[x y] = meshgrid(1:nr,1:nc);
should be
[x y] = meshgrid(1:nc,1:nr);
In fact, meshgrid follows a somewhat odd convention.
Cheers
Alex
Hi Alex,
> It works now ! Thank you very mush for your help. Octaviz is great !
Thank you very much for your help too! You did most of the work!
> While testing octatiz, I have found a bug in the plotting routines: vtk_contour3.m, vtk_meshc.m, vtk_mesh.m and vtk_surf.m.
Thanks for the bug report I'll check it out.
Could you please send me a diff of your sources against cvs version of octaviz? I'd like to integrate your changes into the cvs.
Thanks,
Dragan
Hi Dragan,
I have put the diffs on my website. You can download them at:
http://ocg23.marine.usf.edu/octaviz-0.4.0_cvs.diff
They are produced by:
diff -x*.o -x*.oct -r octaviz/ ../octaviz-0.4.0_64/ > octaviz-0.4.0_cvs.diff
I have only changed the following files:
./Graphics/vtkConeSource.cc
./Wrapping/vtkWrapOctave.c
./Common/vtkInitializeInteractor.cc
./Common/octaviz.cc
./Common/octaviz.h
Cheers
Alex
My DNS has changed. The patch for AMD 64 bit is now available at:
http://ocgmod1.marine.usf.edu/octaviz-0.4.0_cvs.diff
http://131.247.138.93/octaviz-0.4.0_cvs.diff
Alex
Thanks!
Dragan
Dear Octave users,
Please help me. I'm trying to use octaviz on Mandrake linux version 9.1 with the following set of packages, octave-2.1.67 ,VTK-4.4 (-LatestRelease.tar.gz) and octaviz-0.4.0. I've installed these packages by following the steps outlined in the respective readme or install files. Both the vtk and octave seem to work when I test them independently (..i.e I try the vtk examples both tcl and python files..,and I also test some functions in the octave m-files). Whenever I try the vtk .oct and m-files, I get " panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'..." response immedeately...
When I use gdb and run the hello file, I get the following report..
octave:1> hello
[New Thread 16384 (LWP 15859)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 15859)]
octave_user_function::subsref(std::string const&, std::list<octave_value_list, std::allocator<octave_value_list> > const&, int) (this=0x1068,
type=@0x40108682, idx=@0x40108692, nargout=1074824866)
at /usr/include/c++/3.2.2/bits/stl_list.h:126
126 : _List_iterator_base(__x)
Current language: auto; currently c++
(gdb)
Any help is welcome..
Thanks
Most likely you haven't installed vtk data (you can fetch it from vtk.org) which is required by some examples. To avoid this could you please try something more simple like
vtk_plot3( rand(10,1), rand(10,1), rand(10,1) );
an let me know what happend.
Cheers,
Dragan
Thanks for the help..
I do have the vktdata installed under the vtk root directory.. when I try the vtk plot as you suggested, I still got but the seg. fault error but a shorter one ....
octave:1> vtk_plot3( rand(10,1), rand(10,1), rand(10,1) );
Segmentation fault
Thanks
rima
Sorry for late response I was very busy.
I'll need a bit more info before I can help you. In particular I need to know what version of g++ are you using and please send me CMakeCache.txt from octaviz root directory.
Thanks,
Dragan
Dear rima,
I had also some spurious errors when I used the precompiled Octave from Fedora. These problems disappeared when I compiled myself octave, VTK and octaviz. This might be due to different compiler versions or options.
Cheers
Alex