[Paraview-developers] BUILD_SHARED_LIBS=OFF and plugins in 4.2.0 rc1
Burlen Loring
burlen.loring at gmail.com
Fri Sep 19 20:22:16 EDT 2014
Thanks for the explanations!
I did the incremental patch and ninja on both my shared client and
static server builds. I can look closer into it, may be a new issue.
On 09/19/2014 05:08 PM, Utkarsh Ayachit wrote:
> Anycayse, the problem is indeed stemming from a bug that Jean and Alan
> reported earlier about plugins
> (http://www.paraview.org/Bug/view.php?id=14732).
>
> I am going to target this for 4.2.1. Cleaning this up properly may
> take a little more love and care.
>
> Utkarsh
>
> On Fri, Sep 19, 2014 at 7:58 PM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>> Burlen,
>>
>> You did rebuild both the client and the server right? You could not
>> get the same segfault anymore due to this change [1]. The code short
>> circuits when loading a shared lib. The segfault was a happening
>> because the plugin.so from the shared build was being loaded.
>>
>> LoadPlugin() takes the filename indeed. For static builds, however,
>> the filename reported for the distributed plugins is just their name
>> itself. I need to clean that up, but didn't want to make those changes
>> so close to the release. I'll refactor that piece of code for 4.3.
>> Plugin cleanups are long overdue :).
>>
>> [1] http://review.source.kitware.com/#/c/17131/1/ParaViewCore/ClientServerCore/Core/vtkPVPluginLoader.cxx
>>
>> On Fri, Sep 19, 2014 at 7:53 PM, Burlen Loring <burlen.loring at gmail.com> wrote:
>>> Thanks Utkarsh,
>>>
>>> I tested the patch but still had a segv.
>>>
>>> Re: plugins in static linked server, how are they loaded from pvbatch? Does
>>> LoadPlugin call (which takes a file name) work?
>>>
>>>
>>> On 09/19/2014 11:30 AM, Utkarsh Ayachit wrote:
>>>> Burlen,
>>>>
>>>> There are the fixes that should address both the static pvserver not
>>>> finding ".plugins" as well as the issue on your local workstation.
>>>>
>>>> http://review.source.kitware.com/#/t/4692
>>>>
>>>> For the latter, this is more of an hack, but I'll have that addressed
>>>> properly for 4.3.
>>>>
>>>> Utkarsh
>>>>
>>>>
>>>> On Fri, Sep 19, 2014 at 12:05 PM, Burlen Loring <burlen.loring at gmail.com>
>>>> wrote:
>>>>> Thanks for looking into that, and thanks for fixing the .plugins issue!
>>>>> The
>>>>> updated static plugin support in 4.2 is great!
>>>>>
>>>>>
>>>>> On 09/19/2014 08:31 AM, Utkarsh Ayachit wrote:
>>>>>> I spoke too soon, grrrr :~/.
>>>>>>
>>>>>> Utkarsh
>>>>>>
>>>>>> On Fri, Sep 19, 2014 at 11:27 AM, Utkarsh Ayachit
>>>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>>>> Burlen,
>>>>>>>
>>>>>>> I was also able to reproduce the same segfault you're getting on your
>>>>>>> workstation. It seems to be a problem with incremental builds for the
>>>>>>> static build. A clean build (starting with an empty directory)
>>>>>>> addressed the problem for me.
>>>>>>>
>>>>>>> Utkarsh
>>>>>>>
>>>>>>> On Fri, Sep 19, 2014 at 9:49 AM, Utkarsh Ayachit
>>>>>>> <utkarsh.ayachit at kitware.com> wrote:
>>>>>>>> Ah! I know why it's looking for .plugins in the wrong place. I'll push
>>>>>>>> a fix, Thanks!
>>>>>>>>
>>>>>>>> Utkarsh
>>>>>>>>
>>>>>>>> On Thu, Sep 18, 2014 at 7:48 PM, Burlen Loring
>>>>>>>> <burlen.loring at gmail.com>
>>>>>>>> wrote:
>>>>>>>>> Hi Utkarsh,
>>>>>>>>>
>>>>>>>>> I updated to master on both Cray and workstation.
>>>>>>>>>
>>>>>>>>> On the Cray the .plugins file is installed in lib/paraview-4.2. The
>>>>>>>>> PV_PLUGIN_DEBUG output shows that it's expected to be in bin or lib.
>>>>>>>>> Cp'ing
>>>>>>>>> the file into the bin dir fixed that issue, I was able to load and
>>>>>>>>> use
>>>>>>>>> a
>>>>>>>>> plugin!!
>>>>>>>>>
>>>>>>>>> The issues on the Cray and my workstation seem to be unrelated. On
>>>>>>>>> the
>>>>>>>>> workstation I'm seeing the same segv after updating to master. Now it
>>>>>>>>> happens in both build and install during connection. From the stack
>>>>>>>>> it
>>>>>>>>> looks
>>>>>>>>> unrelated to plugins. Happily I don't need the static build on my
>>>>>>>>> workstation, so it's not a huge issue.
>>>>>>>>>
>>>>>>>>> Burlen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09/18/2014 02:36 PM, Utkarsh Ayachit wrote:
>>>>>>>>>> Burlen,
>>>>>>>>>>
>>>>>>>>>> A few things:
>>>>>>>>>> + RGBZView should not be autoloaded since 6575a800a . That happened
>>>>>>>>>> after RC1, I'm afraid.
>>>>>>>>>> + The server would still need a .plugins file (which should be
>>>>>>>>>> autogenerated). Can you verify such a file exists on the Cray? Also,
>>>>>>>>>> try running with PV_PLUGIN_DEBUG set. It should print more info. I
>>>>>>>>>> get
>>>>>>>>>> the following with my static build:
>>>>>>>>>>
>>>>>>>>>>> PV_PLUGIN_DEBUG=1 ./bin/pvserver
>>>>>>>>>> Locate and load distributed plugin list.
>>>>>>>>>> Looking for static plugin '.plugins'
>>>>>>>>>> Loading plugin configuration xml:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> /home/kitware/Dashboards/MyTests/NightlyNext/ParaView-Debug-Static/bin/.plugins
>>>>>>>>>> Trying to locate plugin with name: SLACTools
>>>>>>>>>> Looking for static plugin 'SLACTools'
>>>>>>>>>> Found static plugin 'SLACTools'
>>>>>>>>>> --- Found SLACTools
>>>>>>>>>> ....
>>>>>>>>>> Static build. Skipping PLUGIN_PATHS.Waiting for client...
>>>>>>>>>> Connection URL: cs://blight:11111
>>>>>>>>>> Accepting connection(s): blight:11111
>>>>>>>>>>
>>>>>>>>>> I'm not sure what the RGBZView issue on your workstation is. Mind
>>>>>>>>>> updating to git/master on your workstation to see if the problem
>>>>>>>>>> persists? Actually, if it's only failing for RGBZView, it's less of
>>>>>>>>>> a
>>>>>>>>>> concern than if fails for other plugins too.
>>>>>>>>>>
>>>>>>>>>> Utkarsh
>>>>>>>>>>
>>>>>>>>>> On Thu, Sep 18, 2014 at 5:05 PM, Burlen Loring
>>>>>>>>>> <burlen.loring at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> Hi Utkarsh,
>>>>>>>>>>>
>>>>>>>>>>> Good, glad it's still supported! There seem to be some issues
>>>>>>>>>>> though.
>>>>>>>>>>>
>>>>>>>>>>> On the Cray the remote plugin list is empty except for
>>>>>>>>>>> vtkPVLPuginInitializer. RGBZView is automatically loaded on the
>>>>>>>>>>> client
>>>>>>>>>>> but
>>>>>>>>>>> not the server and thus as soon as the server connects the plugin
>>>>>>>>>>> manager
>>>>>>>>>>> opens to report the issue. The remote plugin list is empty.
>>>>>>>>>>> Browsing
>>>>>>>>>>> to
>>>>>>>>>>> the
>>>>>>>>>>> install and loading the plugin doesn't work. it's a .a file so I'm
>>>>>>>>>>> not
>>>>>>>>>>> surprised. Judging from what I see on my workstation, the remote
>>>>>>>>>>> plugin
>>>>>>>>>>> list
>>>>>>>>>>> should be populated right?
>>>>>>>>>>>
>>>>>>>>>>> I've been trying to reproduce it locally on my workstation. I have
>>>>>>>>>>> different
>>>>>>>>>>> problems. The remote plugin list is fully populated and RGBZView
>>>>>>>>>>> loads on
>>>>>>>>>>> both sides. But when I try to load a plugin via "load selected"
>>>>>>>>>>> ParaView
>>>>>>>>>>> crashes(stack below). That's running from the build. When I try the
>>>>>>>>>>> same
>>>>>>>>>>> on
>>>>>>>>>>> an install the server segv's as soon as I connect. The stack is the
>>>>>>>>>>> same
>>>>>>>>>>> as
>>>>>>>>>>> the in-build crash.
>>>>>>>>>>>
>>>>>>>>>>> By the way this is in client-server mode the server is built with
>>>>>>>>>>> sahred
>>>>>>>>>>> libs off, with mpi and python and without qt.
>>>>>>>>>>>
>>>>>>>>>>> Burlen
>>>>>>>>>>>
>>>>>>>>>>> on local linux workstation, client server, server built without qt,
>>>>>>>>>>> with
>>>>>>>>>>> python and mpi
>>>>>>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>>>>>>> 0x00000000037a44ff in vtkProcessModule::PopActiveSession (this=0x0,
>>>>>>>>>>> session=0xb4880b0) at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /work/ParaView/ParaView/ParaViewCore/ClientServerCore/Core/vtkProcessModule.cxx:473
>>>>>>>>>>> 473 if (this->Internals->ActiveSessionStack.back() !=
>>>>>>>>>>> session)
>>>>>>>>>>>
>>>>>>>>>>> (gdb) where
>>>>>>>>>>> #0 0x00000000037a44ff in vtkProcessModule::PopActiveSession
>>>>>>>>>>> (this=0x0,
>>>>>>>>>>> session=0xb4880b0) at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /work/ParaView/ParaView/ParaViewCore/ClientServerCore/Core/vtkProcessModule.cxx:473
>>>>>>>>>>> #1 0x00000000037f6d94 in vtkSession::DeActivate (this=0xb4880b0)
>>>>>>>>>>> at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /work/ParaView/ParaView/ParaViewCore/ClientServerCore/Core/vtkSession.cxx:39
>>>>>>>>>>> #2 0x00000000034a01c5 in vtkPVSessionBase::ExecuteStream
>>>>>>>>>>> (this=0xb4880b0,
>>>>>>>>>>> location=21, stream=..., ignore_errors=false) at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /work/ParaView/ParaView/ParaViewCore/ServerImplementation/Core/vtkPVSessionBase.cxx:170
>>>>>>>>>>> #3 0x00000000034ac735 in
>>>>>>>>>>> vtkPVSessionServer::OnClientServerMessageRMI
>>>>>>>>>>> (this=0xb4880b0, message=0xbc82030, message_length=16) at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /work/ParaView/ParaView/ParaViewCore/ServerImplementation/Core/vtkPVSessionServer.cxx:552
>>>>>>>>>>> #4 0x00000000034aa8f8 in (anonymous namespace)::RMICallback
>>>>>>>>>>> (localArg=0xb4880b0, remoteArg=0xbc82030, remoteArgLength=16) at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /work/ParaView/ParaView/ParaViewCore/ServerImplementation/Core/vtkPVSessionServer.cxx:56
>>>>>>>>>>> #5 0x000000000489d3c4 in vtkMultiProcessController::ProcessRMI
>>>>>>>>>>> (this=0xbc79460, remoteProcessId=1, arg=0xbc82030, argLength=16,
>>>>>>>>>>> rmiTag=55625) at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /work/ParaView/ParaView/VTK/Parallel/Core/vtkMultiProcessController.cxx:774
>>>>>>>>>>> #6 0x000000000489cf98 in vtkMultiProcessController::ProcessRMIs
>>>>>>>>>>> (this=0xbc79460, reportErrors=0, dont_loop=1) at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /work/ParaView/ParaView/VTK/Parallel/Core/vtkMultiProcessController.cxx:720
>>>>>>>>>>> #7 0x00000000037f8ae7 in
>>>>>>>>>>> vtkTCPNetworkAccessManager::ProcessEventsInternal
>>>>>>>>>>> (this=0xb461a70, timeout_msecs=0, do_processing=true) at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /work/ParaView/ParaView/ParaViewCore/ClientServerCore/Core/vtkTCPNetworkAccessManager.cxx:268
>>>>>>>>>>> #8 0x00000000037f868a in vtkTCPNetworkAccessManager::ProcessEvents
>>>>>>>>>>> (this=0xb461a70, timeout_msecs=0) at
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /work/ParaView/ParaView/ParaViewCore/ClientServerCore/Core/vtkTCPNetworkAccessManager.cxx:165
>>>>>>>>>>> #9 0x0000000001c6d896 in RealMain (argc=1, argv=0x7fff33cd48f8,
>>>>>>>>>>> type=vtkProcessModule::PROCESS_SERVER) at
>>>>>>>>>>> /work/ParaView/ParaView/CommandLineExecutables/pvserver_common.h:91
>>>>>>>>>>> #10 0x0000000001c6d94f in main (argc=1, argv=0x7fff33cd48f8) at
>>>>>>>>>>> /work/ParaView/ParaView/CommandLineExecutables/pvserver.cxx:27
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 09/18/2014 05:37 AM, Utkarsh Ayachit wrote:
>>>>>>>>>>>> Yes, you need to load them manually, however. They are no longer
>>>>>>>>>>>> auto-loaded.
>>>>>>>>>>>>
>>>>>>>>>>>> http://www.paraview.org/Bug/view.php?id=14542
>>>>>>>>>>>>
>>>>>>>>>>>> Utkarsh
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Sep 17, 2014 at 7:35 PM, Burlen Loring
>>>>>>>>>>>> <burlen.loring at gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm having trouble with our NERSC install, plugins don't seem to
>>>>>>>>>>>>> be
>>>>>>>>>>>>> working
>>>>>>>>>>>>> at all. Should plugins work with BUILD_SHARED_LIBS=OFF in 4.2?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Burlen
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Paraview-developers mailing list
>>>>>>>>>>>>> Paraview-developers at paraview.org
>>>>>>>>>>>>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>>>>>>>>>>
More information about the Paraview-developers
mailing list