Crash when running <root>/tutorials/eve/<scripts> with Singularity

[WanbingHe]

Dear Experts,

I’m trying to run a “event display” macro with a Singularity image (CentOS8.2), and got the following crash:

Error in : BadMatch (invalid parameter attributes) (TGVerticalFrame XID: 46138020, XREQ: 1)
TGVerticalFrame: 46138020
TGLSAFrame: 46138009
TGCompositeFrame: 46138008

This looks like a problem with GL libs. But my Geant4 works well with GL libs.

---

FYI: glxinfo gives following:

display: localhost:10 screen: 0
direct rendering: Yes
server glx vendor string: Brian Paul
server glx version string: 1.4 Mesa 20.1.3
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile,
…
client glx vendor string: Brian Paul
client glx version string: 1.4 Mesa 20.1.3
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile,
…
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile,
…
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: llvmpipe (LLVM 9.0.1, 256 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 20.1.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend,
…

OpenGL version string: 3.1 Mesa 20.1.3
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend,
…

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.1.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5,
…

2 GLX Visuals
visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat

0x021 24 tc 0 24 0 r y . 8 8 8 8 . . 0 24 8 16 16 16 16 0 0 None
0x064 32 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 16 16 16 0 0 0 None

2 GLXFBConfigs:
visual x bf lv rg d st colorbuffer sr ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a F gb bf th cl r g b a ns b eat

0x021 24 tc 0 24 0 r y . 8 8 8 8 . . 0 24 8 16 16 16 16 0 0 None
0x064 32 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 16 16 16 16 0 0 None

---

---

ROOT Version: 6.23/01
Platform: Singularity (CentOS Linux release 8.2.2004)
Compiler: gcc version 8.3.1 20191121 (Red Hat 8.3.1-5)

---

[linev]

May be @matevz has some idea

[matevz]

GLX visuals / frambuffs look ok, RootGL requires 8bit rgba, 16 bit depth and 8 bit stencil buffs … you would see an explicit message if these wouldn’t be fulfilled.

It seems like X gets confused somehow. What is your host OS and what window system is it running, in particular, is it Wayland?

How complex is your event display macro? Do simple tutorials in tutorials/eve give you the same result? E.g., the simplest is pointset.C.

Does tutorials/gl/glViewerLOD.C work? This opens just the GL window, without embedding it into the Eve main window.

[WanbingHe]

Hi @matevz,

Thanks for help.

My host OS is Ubuntu18.04. It isn’t Wayland on the host. $XDG_SESSION_TYPE=“x11”.

Yes, every macros in tutorials/eve give the same result.

Running tutorials/gl/glViewerLOD.C gives the same result.

---

I find it works when I use a MacOS with XQuartz as a client to ssh to the host remotely.

So far, I tested it in the following ways:

1. Singularity(CentOS8)+Host(Ubuntu18.04, X11) Not work
2. Singularity(CentOS8)+Host(Ubuntu18.04, X11) + Client(Ubuntu18.04, X11) Not work
3. Singularity(CentOS8)+Host(Ubuntu18.04, X11) + Client(MacOS XQuartz) Works!

[matevz]

Hmmh, so your option 1. is running on the machine where singularity is installed and 2. is ssh-ing into it, right?

I assume native build on ubuntu-18.4 works ok. Have you tried this?

The way one debugs these things is like this:

1. enable synchronous X11 mode in .rootrc:
   X11.Sync: on
2. run root.exe in debugger and set the breakpoint on x11 error handler, I forgot exactly where this is, I’ll look later.

With this, you can then see exactly which X11 call causes trouble.

The function is RootX11ErrorHandler() in ./graf2d/x11/src/GX11Gui.cxx:
https://github.com/root-project/root/blob/master/graf2d/x11/src/GX11Gui.cxx#L171

Is there anything else printed out when the error is hit, other than the BadMatch you had in your original post?

Cheers,
Matevz

[WanbingHe]

Hi Matevz,

Yes, from “Client”, ssh into “Host”

Yes, The native build works ok on ubuntu-18.4 without singularity.

When the breakpoint at “GX11Gui.cxx:171” is hit by the error, only the same info is printed out, northing more.

Thanks!
Wanbing

[matevz]

Hi Wanbing,

Sigh, I’m running out of ideas here

What are your GL drivers on the host? You could try installing the same one in singularity or even just copying over libGL.so and LD_PRELOAD it (and maybe, but I think not, also libglx.so) … this is a trick that used to work for me doing ssh into CERN: remote GL did not work with their GL, but if I copied over libGL from NVIDIA, it did. Strange world we live in

If you are able to run that in the debugger with sync on and stop at the error … would you be able to figure out which X11 call was actually causing it? I forgot how this works … but don’t you see it in the backtrace (assuming you turned on X11.Sync)?

Cheers,
Matevz

[WanbingHe]

I installed Mesa, which will replace the original libGL.so . This GL driver can make 3D graphic rendered with remote ssh. I didn’t use libGL from NVIDIA, because I need it works on a computing cluster without GPU.

I didn’t get “which X11 call”. I run gdb as debugger with “X11.Sync:on” in .rootrc, and checked it by “gEnv->Print()” . When the breakpoint hit, debugger prints out "Thread 1 “root.exe” hit Breakpoint 1, RootX11ErrorHandler (disp=0x2db1a00, err=0x7fffffff9960) at /opt/root_src/graf2d/x11/src/GX11Gui.cxx:174
174 XGetErrorText(disp, err->error_code, msg, 80);
"

Cheers,
Wanbing

[matevz]

My point was that Mesa GL in singularity might have trouble talking to the one on host for some reason … and that you should try sticking in and preloading the same one you use on the host.

Which GL drivers do you use on the host?

What is the full backtrace of the error? As I said, I’m not super sure if you will see the actual X11 call that caused it (I haven’t done in 5+ years, knock on wood) … but I think you should.

Cheers,
Matevz