[vtk-developers] VTK Wrapping

Tue Jul 13 10:52:05 EDT 2010

Thanks for looking into it.  Yes, I would expect the module to be loaded
twice.  The main thing going on is that vtkCPPythonScriptPipeline
initializes paraview's python core which creates a new interp with the
python c-api Py_NewInterpreter().  The new interp will have its own copy of
all modules, __builtin__, __main__, and sys.

http://docs.python.org/c-api/init.html#Py_NewInterpreter

Pat

On Tue, Jul 13, 2010 at 10:15 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> Another small discrepancy that I noticed is that the first time the
> module loads, it loads with the path
> /beck/data/dgobbi/Kitware/ParaView-gitbin/bin/./libvtkCommonPython.so
> and the second time, it loads with the path
> /beck/data/dgobbi/Kitware/ParaView-gitbin/bin/libvtkCommonPython.so
> i.e. there is an extra "./" the first time around.  This is probably
> just a red herring, but I thought it was worth mentioning.
>
>   David
>
>
> On Mon, Jul 12, 2010 at 11:51 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> > Hi Pat,
> >
> > The problem is that libvtkCommonPython is being loaded twice.  I have
> > added an "if" check to get rid of the segfault, but still, there seems
> > to be something fishy about the way that the interpreter is loading
> > the modules.
> >
> > Whenever a module is loaded, it should appear in "sys.modules", but
> > after calling cp.vtkCPPythonScriptPipeline(), when I do
> > "dir(sys.modules)" I don't see any of the VTK modules.  This could be
> > because the modules are being loaded into a separate interpreter, I
> > don't know what vtkCPPythonScriptPipeline() does.  But in any case,
> > because libvtkCommonPython isn't added to sys.modules, calling "import
> > libvtkCommonPython" causes the module initialization code to be
> > re-executed.  And that is what was causing the segfault.
> >
> >   David
> >
> >
> > On Mon, Jul 12, 2010 at 4:45 PM, pat marion <pat.marion at kitware.com>
> wrote:
> >> Hi David,
> >>
> >> I uncovered a new segfault.  Admittedly this is a very strange case, but
> it
> >> used to work:
> >>
> >> import libvtkCoProcessorPython as cp
> >> pipeline = cp.vtkCPPythonScriptPipeline()
> >>
> >> # crash here
> >> import libvtkCommonPython
> >>
> >> Run with vtkpython, or regular python.  You might need to add
> >> /path/to/paraview-build/bin to sys.path.  You get the
> vtkCoProcessorPython
> >> library if you build paraview with python and
> PARAVIEW_ENABLE_COPROCESSING.
> >>
> >> Here is what is happening- the ctor of vtkCPPythonScriptPipeline
> initializes
> >> paraview (vtkPVMain::Initialize), creates a vtkPVPythonInterpretor, and
> >> execs code in the new interpreter that imports vtk modules.  If it makes
> any
> >> difference, the vtk that is imported is paraview/vtk/__init__.py, not
> the
> >> regular vtk/__init__.py.  Note, it doesn't crash if I import
> >> libvtkFilteringPython, or any other kit, just vtkCommon.  I guess
> because
> >> vtkCommon contains the specially wrapped vtkTimeStamp.
> >>
> >>
> >>
> >> backtrace-
> >>
> >> 0x00007fffe43c6bfe in PyVTKSpecialType_New (newmethod=0x7fffe4a18180,
> >> methods=0x7fffe4a180e0, constructors=0x7fffe4a18140,
> >>     classname=0x7fffe47a310e "vtkTimeStamp", docstring=0x7fffe4a181e0,
> >> smethods=0x7fffe4a181a0)
> >>     at
> >> /source/paraview/ParaView/VTK/Wrapping/Python/PyVTKSpecialObject.cxx:341
> >> 341      newmethod->ml_doc = PyString_AsString(info->docstring);
> >>
> >> (gdb) bt
> >> #0  0x00007fffe43c6bfe in PyVTKSpecialType_New
> (newmethod=0x7fffe4a18180,
> >> methods=0x7fffe4a180e0, constructors=0x7fffe4a18140,
> >>     classname=0x7fffe47a310e "vtkTimeStamp", docstring=0x7fffe4a181e0,
> >> smethods=0x7fffe4a181a0)
> >>     at
> >> /source/paraview/ParaView/VTK/Wrapping/Python/PyVTKSpecialObject.cxx:341
> >> #1  0x00007fffe46fbb4a in PyVTKClass_vtkTimeStampNew () at
> >> /source/paraview/build/VTK/Common/vtkTimeStampPython.cxx:164
> >> #2  0x00007fffdd07cf4c in initlibvtkCommonPython () at
> >> /source/paraview/build/VTK/Common/vtkCommonPythonInit.cxx:1055
> >> #3  0x00000000004c081c in _PyImport_LoadDynamicModule ()
> >> #4  0x00000000004bed93 in ?? ()
> >> #5  0x00000000004bf00f in ?? ()
> >> #6  0x00000000004bf6cb in ?? ()
> >> #7  0x00000000004bfc14 in PyImport_ImportModuleLevel ()
> >> #8  0x00000000004a16ab in ?? ()
> >> #9  0x000000000041f0c7 in PyObject_Call ()
> >> #10 0x00000000004a226f in ?? ()
> >> #11 0x00000000004a55fc in PyEval_EvalFrameEx ()
> >> #12 0x00000000004a9671 in PyEval_EvalCodeEx ()
> >> #13 0x00000000004a9742 in PyEval_EvalCode ()
> >> #14 0x00000000004c9a0e in PyRun_FileExFlags ()
> >> #15 0x00000000004c9c24 in PyRun_SimpleFileExFlags ()
> >> #16 0x000000000041a7ff in Py_Main ()
> >>
> >>
> >> On Tue, Jul 6, 2010 at 9:51 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >>>
> >>> Hi All,
> >>>
> >>> Another wrapping update was pushed this morning.  This time, the
> >>> parser and the wrappers have been updated so that they can build while
> >>> ignoring the BTX/ETX markers in the header files. Here is a new CMake
> >>> variable for people to play with:
> >>>
> >>> VTK_IGNORE_BTX "Ignore BTX and ETX in header files."
> >>>
> >>> If you turn this option ON, then the wrappers will parse the header
> >>> files as if all the BTX/ETX markers had were removed, i.e. //BTX and
> >>> //ETX will be treated as if they were just regular comments.
> >>>
> >>> Turning on this option will break any external wrapping, e.g. ParaView
> >>> or Titan, because I do not yet export the hierarchy files.  For now,
> >>> it is just an experimental option for stand-alone VTK builds.
> >>>
> >>>   David
> >>> _______________________________________________
> >>> Powered by www.kitware.com
> >>>
> >>> Visit other Kitware open-source projects at
> >>> http://www.kitware.com/opensource/opensource.html
> >>>
> >>> Follow this link to subscribe/unsubscribe:
> >>> http://www.vtk.org/mailman/listinfo/vtk-developers
> >>>
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100713/59de1fc1/attachment.html>