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