[Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on.

Tue Apr 19 12:29:14 EDT 2011

Dear Kevin!

To put things more clearly and to avoid confusion, I'd like to build a paraview v3.10.x executable with X. In this regard, I'd like to use paraview as the client and start remotely the paraview server with mpirun -np <N> --use-offscreen-rendering. Following the description on the Paraview WIKI,

http://paraview.org/Wiki/ParaView/Users_Guide/Parallel_Rendering#Offscreen_software_rendering_via_OSMesa

I *should* be able to build paraview with X using offscreen rendering, based on the MESA libraries. Again, this worked with paraview v3.8.1, but I fail getting it up and running with paraview 3.10.x performing the same configuration steps as with paraview 3.8.1.

If I understood you well, one cannot link an application to libOSMESA.so and libGL.so/libGLU.so at the same time. If this is correct, then it would explain why I get a segmentation fault straight away. On the other hand, what are then the libGL.so and libGLU.so one has to link against, if not the ones from MESA v7.x according to the WIKI:

[...]
You can use it as a supplement to onscreen rendering. This mode requires that you have a display (X11 is running). In addition to specifying the GL library (which may be a GPU implementation of the Mesa one above), you must tell ParaView where Mesa's OSMesa library is. Do that by turning the VTK_OPENGL_HAS_OSMESA variable to ON. After you configure again you will see a new CMake variable called OSMESA_LIBRARY. Set this to the libOSMesa library file.

PARAVIEW_BUILD_QT_GUI   ON
VTK_USE_COCOA           ON                              Mac Only. X11 is not supported.
VTK_OPENGL_HAS_OSMESA   ON                              Turn this to ON to enable software rendering.
OSMESA_INCLUDE_DIR      <mesa include dir>      Set this to the include directory for MESA.
OPENGL_INCLUDE_DIR      <mesa include dir>      Set this to the include directory for MESA.
OPENGL_gl_LIBRARY       libGL                   Set this to the libGL.a or libGL.so file.
OPENGL_glu_LIBRARY      libGLU                  Set this to the libGLU.a or libGLU.so file.
OSMESA_LIBRARY          libOSMesa                       Set this to the libOSMesa.a or libOSMesa.so file.

If one tries to use the libGL.so/libGLU.so libraries, here is the output of CMake, wether you use the mesa include dir or the system include dir for OPENGL_INCLUDE_DIR.

[...]
CMake Warning at VTK/CMake/vtkTargetExportMacros.cmake:6 (ADD_LIBRARY):
   Cannot generate a safe runtime search path for target vtkftgl because files
   in some directories may conflict with libraries in implicit directories:

     runtime library [libGL.so.1] in /usr/lib64 may be hidden by files in:
       /code/CFD/develop/opt/share/Mesa-7.9.2/lib

   Some of these libraries may not be found correctly.
 Call Stack (most recent call first):
   VTK/Utilities/ftgl/CMakeLists.txt:151 (VTK_ADD_LIBRARY)
[...]

. Please correct me if I am wrong, but everything points me towards using the libGL.so and libGLU.so from the MESA libs installation.

Finally, there is now an additional setup variable OPENGL_xmesa_INCLUDE_DIR. Where should this variable point to? With GPU support, this points to the system include files.

Thank you very for your help anyway and please let me know if you have made any progress with building paraview on your cluster.

Cheers,

Frank.

-----Original Message-----
From: Kevin H. Hobbs [mailto:hobbsk at ohio.edu]
Sent: Dienstag, 19. April 2011 13:23
To: Albina, Frank
Cc: David Partyka; paraview at paraview.org
Subject: Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on.

On 04/19/2011 01:59 AM, Albina, Frank wrote:
> Hi Kevin!
>
> Thanks a lot for the offer. To be honest, I am still having trouble to run paraview v3.10.0/v3.10.1 to have CPU rendering only with additional X support.

This statement confuses me.

There are two* ways to build paraview :

1. With X : Hardware accelerated or not, onscreen or not, X is required.

2. Without X : No hardware acceleration, always offscreen, X is not required at all.

*OK, OK there are other window systems for Mac and Windows

> On the one hand, I am performing the same configuration steps with CMake as for paraview 3.8.1, for which I have had no issues whatsoever wrt. running paraview in this configuration for the last 4 months. I am relying heavily on paraview for post-processing simulation results and it runs on my compute cluster daily in parallel.
>
> On the other hand, performing the same configuration steps with CMake for paraview 3.10.0 or 3.10.1 creates an executable which cannot run without producing a segmentation fault, which does appear just after the logo window has popped up. For information, I am compiling the paraview sources from scratch.

After I'm sure you have Mesa and PV builds that will work we'll check that you are linking against the right libraries.

I can't tell you how many times I've thought I've set up Mesa correctly only to discover that PV was linking against the system GL.

> Here are the settings I am using by default:
>
> OPENGL_gl_LIBRARY:FILEPATH=/code/CFD/develop/opt/share/Mesa-7.9.2/lib/
> libGL.so

The above is an Open GL library.

> OSMESA_LIBRARY:FILEPATH=/code/CFD/develop/opt/share/Mesa-7.9.2/lib/lib
> OSMesa.so
>

The above is also an Open GL library you can not link an application to both of them at the same time.

>> make realclean
>> ./configure --prefix=/code/CFD/develop/opt/share/Mesa-7.9.2 --with-x
>> --enable-gl-osmesa --build=x86_64-suse-linux --with-driver=xlib
>> --enable-glu --enable-glw --enable-pic --enable-opengl make -j 4 make
>> install

Though this creates an OSMesa library and a GL library they can not be linked together.

I don't remember all of the details but:

    1. long ago OSMesa could be built one of two ways
        1.1 Stand alone OSMesa could not be linked to GL :
offscreen only
        1.2 OSMesa had to be linked to GL : offscreen or onscreen

    2. Now OSMesa can be built only one way which is the same as 1.1.

Paraview has also changed over that time

> Furthermore, the problem does not arise when I am disabling MPI
> support (i.e. VTK_USE_MPI:INTERNAL=OFF)

I can not explain this part.

> I would be very grateful if you could help me find out was I could be doing wrong. Again, the procedure works for paraview v3.8.1, so I am quite at loss when it does not work anymore for paraview v3.10.x.
>
> Please, let me know if you need more information.

Well I need to update the software I have on our cluster anyway.

I might as well do it today.

As I work I'll make a script out of the steps.

I'll share the script with you.