Personal tools
You are here: Home Forum Use SALOME 8.4 SMESH crashes under VirtualGL

SALOME 8.4 SMESH crashes under VirtualGL

Up to Use

SALOME 8.4 SMESH crashes under VirtualGL

Posted by Leon Kos at March 07. 2018

On CentOS 7 a pre-compiled binary and rebuild from sources Salome 8.4 crashes when selecting SMESH module. It returns:

[VGL] ERROR: in TempContext--
[VGL]    52: Could not bind OpenGL context to window (window may have disappeared)

Strangely, it crashes only in SMESH and not in GEOM or ParaVIS modules that use VirtualGL just fine. So the problem seems to be with SMESH and newer versions of Qt because if I rebuild Salome 8.4 with Qt-5.6.1-1 from Salome 8.3 it works.

I have tried also to downgrade to Qt 5.7.1 and upgrade to 5.10.1 without luck. Also new version of VirtualGL 2.5.1 does not help here.

So, I am stuck with Qt-5.6.1-1 workaround with Salome 8.4 running on two VirtualGL clusters.

Any suggestion what the cause might be?

Re: SALOME 8.4 SMESH crashes under VirtualGL

Posted by Leon Kos at August 05. 2018

The situation with VirtualGL didn't changed with new 8.5 SALOME release although there is new MESA with LLVM imposter. :( 

Previously Leon Kos wrote:

So, I am stuck with Qt-5.6.1-1 workaround with Salome 8.4 running on two VirtualGL clusters.

 

Re: SALOME 8.4 SMESH crashes under VirtualGL

Posted by Christophe Bourcier at September 24. 2018

Hi,

This issue has been fixed in VirtualGL 2.6. It works for me with Salome 8.4.0, 8.5.0 and new coming 9.2.0.

See the ChangeLog:

5. Worked around a segfault in Mayavi2 (and possibly other VTK applications)
when using nVidia's proprietary drivers.  VirtualGL's implementation of
`glXGetVisualFromFBConfig()` always returned a TrueColor X visual, regardless
of the GLXFBConfig passed to it.  From VirtualGL's point of view, this was
correct behavior, because VGL always converts the rendered 3D pixels to
TrueColor when reading them back.  However, some use cases in VTK assume that
there is a 1:1 correspondence between X visuals and GLX FB configs, which is
not the case when using VirtualGL.  Thus, VGL's implementation of
`glXGetVisualFromFBConfig()` was causing VTK's visual matching algorithm to
always select the last FB config in the list, and when using nVidia hardware,
that FB config usually describes an esoteric floating point pixel format.  When
VTK subsequently attempted to create a context with this FB config and make
that context current, VirtualGL's internal call to `glXMakeContextCurrent()`
failed.  VGL passed this failure status back to VTK in the return value of
`glXMakeCurrent()`, but VTK ignored it, and the lack of a valid context led to
a subsequent segfault when VTK tried to call `glBlendFuncSeparate()`.
VirtualGL's implementation of `glXGetVisualFromFBConfig()` now returns NULL
unless the FB config has a corresponding visual on the 3D X server.

 

Powered by Ploneboard
Document Actions