ROOT graphics over X11: No good OpenGL visual found!

I think @matevz can help you.

One more update (as told by the system admin of the machine I’m using). Most likely I am using my local video card to render OpenGL tasks, because I am tunneling with X11… Unfortunately my own video card does not support OpenGL, which I why I wanted to do visualization remotely in the first place!

So basically I would want to do the processing of ROOT graphics on the remote machine (with a GPU of my choosing) and tunnel the output to my local display… Is this possible at all? Sorry if this falls out of the scope of ROOT; I think this is a more general question, but maybe there is an someone who can help me with this?

What is your local setup? Unless you’re trying to visualize something extremely complex your local machine, even with software rendering should be ok. Root gl will asks for 8-bit RGBA + 16-bit depth and 8-bit stencil buffers. What visuals does glxinfo report there? You can put th eoutput on the web somewhere if you want to take a look. Maybe all you need to do is to enable true color / 24-bit colors.

To do true remote rendering and only transfer images you could use x2go client … if, of course, the remote site supports (or is willing to support) x2go server. I actually use it quite often, also for work with root gl/eve.


The local setup is a Windows machine that runs Ubuntu as a virtual machine. I need Ubuntu for the project that uses ROOT for visualization. The virtual machine makes it difficult for me to use OpenGL functionality that comes with my graphics card. Here is the output of glxinfo:

Every time I run a ROOT-driving graphics application I get either segmentation faults or invalid pointer errors that immediately crash the app (tried several of the examples in $ROOTSYS/tutorials/eve.

I will get a new machine in a few weeks time, I will install Ubuntu natively on that to avoid virtualizing my GPU, so this remote solution is more a solution for the time being. I will try to see if x2go server can be installed on the remote machine. Thanks!

Yes, in VM you won’t get good performance, but it should still work. Crank up the graphics settings for the VM to the maximum. Also look for graphics settings in desktop manager to make sure you have 8-bit colors.

In my VM it actually renders fine and I can play with the 3D object, but only for a short while, because of the segmentation fault or invalid pointer error I will get every time. The color depth of my VM is 24 bit btw.

Example of segfault:

There was a crash.
This is the entire stack trace of all threads:
#0  0x00007f1fc1aa654c in __libc_waitpid (pid=4310, stat_loc=stat_loc
entry=0x7ffdd7cb1600, options=options
entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:31
#1  0x00007f1fc1a28232 in do_system (line=<optimised out>) at ../sysdeps/posix/system.c:148
#2  0x00007f1fc2589e43 in TUnixSystem::StackTrace() () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#3  0x00007f1fc258bc2c in TUnixSystem::DispatchSignals(ESignals) () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#4  <signal handler called>
#5  strlen () at ../sysdeps/x86_64/strlen.S:106
#6  0x00007f1fa12549cc in llvm::MemoryBuffer::getMemBufferRef() const () from /usr/lib/x86_64-linux-gnu/
#7  0x00007f1fa0d30063 in llvm::MCJIT::generateCodeForModule(llvm::Module*) () from /usr/lib/x86_64-linux-gnu/
#8  0x00007f1fa0d2df80 in llvm::MCJIT::finalizeObject() () from /usr/lib/x86_64-linux-gnu/
#9  0x00007f1fa0b93262 in LLVMGetPointerToGlobal () from /usr/lib/x86_64-linux-gnu/
#10 0x00007f1fa2b4bc59 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#11 0x00007f1fa2b4d025 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#12 0x00007f1fa2a84e1f in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#13 0x00007f1fa2a7e04f in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#14 0x00007f1fa2a7e537 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#15 0x00007f1fa29532fd in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#16 0x00007f1fa293cdea in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#17 0x00007f1fa2817992 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#18 0x00007f1fa282b552 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#19 0x00007f1fac16d61f in TGLPhysicalShape::Draw(TGLRnrCtx&) const () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#20 0x00007f1fac1604f1 in TGLScene::RenderElements(TGLRnrCtx&, std::vector<TGLScene::DrawElement_t*, std::allocator<TGLScene::DrawElement_t*> >&, bool, std::vector<TGLPlane, std::allocator<TGLPlane> > const*) () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#21 0x00007f1fac160a1f in TGLScene::RenderAllPasses(TGLRnrCtx&, std::vector<TGLScene::DrawElement_t*, std::allocator<TGLScene::DrawElement_t*> >&, bool) () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#22 0x00007f1fac192311 in TGLViewerBase::SubRenderScenes(void (TGLSceneBase::*)(TGLRnrCtx&)) () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#23 0x00007f1fac192554 in TGLViewerBase::RenderOpaque(bool, bool) () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#24 0x00007f1fac191c27 in TGLViewerBase::Render() () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#25 0x00007f1fac132a71 in TGLViewer::DoSelect(int, int) () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#26 0x00007f1fac169f64 in TGLEventHandler::SelectForMouseOver() () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#27 0x00007f1fac16a988 in TGLEventHandler::HandleTimer(TTimer*) () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#28 0x00007f1fc24eb977 in TTimer::Notify() () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#29 0x00007f1fc24eb8d1 in TTimer::CheckTimer(TTime const&) () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#30 0x00007f1fc258bb79 in TUnixSystem::DispatchTimers(bool) () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#31 0x00007f1fc258c4f0 in TUnixSystem::DispatchOneEvent(bool) () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#32 0x00007f1fc24b78c6 in TSystem::InnerLoop() () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#33 0x00007f1fc24b8510 in TSystem::Run() () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#34 0x00007f1fc24af85f in TApplication::Run(bool) () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#35 0x00007f1fc28f5e55 in TRint::Run(bool) () from /home/ahmad/Desktop/root_v6.08.06_prebuilt/root/lib/
#36 0x00000000004010ac in main ()

What’s wrong with it?

Btw: with which kind of configuration are you setting up your X2Go solution?

I’d say it gets stuck in display list execution. People were reporting those and I never got a chance to do a workaround / problem detection. The solution is to disable display lists for problematic GL renderer classes, e.g., by uncommenting a line like this (or adding it) in the constructor:

What do you mean by “what kind of config for x2go”? I use client on linux and mac and there is a native windows client, too.

Ok, so that’s a little tedious. It would require me to first find out what kind of renderer classes I will depend on for my visualization and then rebuild ROOT with these adjusted constructors…

It would be nice if I could do the visualization remotely.

What do you mean by “what kind of config for x2go”?

Well, the system admin installed X2Go Server on the remote machine. I installed X2Go client on my Windows machine. But when I try to run an example in $ROOTSYS/tutorials/eve/ I again get the error in my first post…So I get that in both cases: X11 tunneling and X2Go… He uses MATE as the desktop binding. And only software rendering is available. Did you set any specific configuration?

The glxinfo output of the remote machine (through X2Go) can be found here:

Any thoughts?

Argh, I thought you’d get nvidia gl on the remote … i do on my desktop. I didn’t set anything, it just picked up the default libGL. But I do use the machine as desktop so Xorg is set to use nvidia glx, too.

Are you willing to build your own root and bear with me while I implement the display list switch through .rootrc? I started working on it in Feb 2016 and then my desktop mobo died and I never got back to it after I got the computer back … I found the code so I should be able to commit the first version tonight (Pacific time).

If yes, would you mind listing the eve/gl classes that you use? I know all renderers that use gl vertex arrays are affected … just want to make sure we get the majority of them on the first iteration.

I did the first pass for disabling of display lists … you can only disable them completely, for all GL objects, by setting in your rootrc:
OpenGL.UseDisplayLists: 0

You’ll need to pick this branch:

And this is the commit with some more info:

The next step is to over all the GL rendering classes and selectively disable display lists for those that use vertex arrays.

Thanks a lot for looking into the display list switch again. I wouldn’t mind a custom build of ROOT for the time being.

would you mind listing the eve/gl classes that you use?

For now I just use the following Eve classes for my initial visualization setup:

  • TEveBrowser.h
  • TEveGeoNode.h
  • TEveManager.h

which eventually call upon TGLViewerBase and TGLViewer which will do the actual rendering that result in my segfaults and also in the tutorials/eve examples.

I will try to work with your branch and turn off the display list switch to see if it stops the segfaults.

But I do use the machine as desktop so Xorg is set to use nvidia glx, too.

Btw, do you mind sharing your xorg.conf file?

If you only use TGeo then it’s probably the TGLCylinder … but it could also be anything using GLU quadrics.

Abot xorg.conf … I only have what is put in by the nvidia installer:

matevz@desire ~> cat /etc/X11/xorg.conf.d/99-nvidia.conf
#This file is provided by xorg-x11-drv-nvidia
#Do not edit

Section "Files"
        ModulePath   "/usr/lib64/nvidia/xorg"
        ModulePath   "/usr/lib64/xorg/modules"

matevz@desire ~> rpm -qa | grep nvidia

So I build your branch with the DisplayLists for all GL objects turned off, but I get the following segfault when trying to render an example from $ROOTSYS/tutorials/eve:

There was a crash.
This is the entire stack trace of all threads:
#0  0x00007f91dc81b54c in __libc_waitpid (pid=1609, stat_loc=stat_loc
entry=0x7ffff4cdc800, options=options
entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:31
#1  0x00007f91dc79d232 in do_system (line=<optimised out>) at ../sysdeps/posix/system.c:148
#2  0x00007f91dd306489 in TUnixSystem::StackTrace (this=0x1ab18e0) at /home/ahmad/Desktop/root-vizbugfix/root/core/unix/src/TUnixSystem.cxx:2412
#3  0x00007f91dd30813c in TUnixSystem::DispatchSignals (this=0x1ab18e0, sig=kSigSegmentationViolation) at /home/ahmad/Desktop/root-vizbugfix/root/core/unix/src/TUnixSystem.cxx:3632
#4  <signal handler called>
#5  strlen () at ../sysdeps/x86_64/strlen.S:106
#6  0x00007f91bce9c9cc in llvm::MemoryBuffer::getMemBufferRef() const () from /usr/lib/x86_64-linux-gnu/
#7  0x00007f91bc978063 in llvm::MCJIT::generateCodeForModule(llvm::Module*) () from /usr/lib/x86_64-linux-gnu/
#8  0x00007f91bc975f80 in llvm::MCJIT::finalizeObject() () from /usr/lib/x86_64-linux-gnu/
#9  0x00007f91bc7db262 in LLVMGetPointerToGlobal () from /usr/lib/x86_64-linux-gnu/
#10 0x00007f91be793c59 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#11 0x00007f91be795025 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#12 0x00007f91be6cce1f in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#13 0x00007f91be6c604f in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#14 0x00007f91be6c6537 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#15 0x00007f91be59b2fd in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#16 0x00007f91be594a63 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#17 0x00007f91be50ca13 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#18 0x00007f91c7a5c880 in TGLUtil::DrawNumber (num=..., pos=..., center=center
entry=true) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLUtil.cxx:2622
#19 0x00007f91c7a62004 in TGLUtil::DrawSimpleAxes (camera=..., bbox=..., axesType=1) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLUtil.cxx:2578
#20 0x00007f91c7a66b85 in TGLViewer::DrawGuides (this=this
entry=0x5eaf780) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLViewer.cxx:1181
#21 0x00007f91c7a688fd in TGLViewer::Render (this=0x5eaf780) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLViewer.cxx:519
#22 0x00007f91c7a6661c in TGLViewer::DoDrawMono (this=this
entry=0x5eaf780, swap_buffers=swap_buffers
entry=true) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLViewer.cxx:634
#23 0x00007f91c7a68fe9 in TGLViewer::DoDraw (this=0x5eaf780, swap_buffers=<optimised out>) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLViewer.cxx:596
#24 0x00007f91dda824c5 in ?? ()
#25 0x00007f91dd5ee7b0 in vtable for TString () from /home/ahmad/Desktop/root-vizbugfix/root/buildroot/lib/
#26 0x0000002200000031 in ?? ()
#27 0x0000000006120360 in ?? ()
#28 0x00007ffff4ce0c50 in ?? ()
#29 0x0000000000000000 in ?? ()

OK … so we’re moving on … this is now crashing in ftgl font rendering :slight_smile:

It’s an external library assimilated into root that also uses display lists. I have control over our clone … I’ll take a look to see how hard it would be to disable display lists there.

Stay tuned,

As you can see from the stack trace, this crashes when trying to draw labels for the crude red/green/blue axes … can you live with disabling them for now?

IIRC, this uses pixel fonts (i.e., glDrawPixels). I’ll try to look into this this evening and hopefully have an update.

I went through the code and this is strange. Numbers on gl-viewer builtin guides are drawn from static arrays using glBitmap directly. The thing crashes in glRasterPos3dv() that is supposed to set window pixel coordinates where the number is to be drawn.

I guess you are not creating the viewer within a minimized/unmapped parent container window … that’s about the only scenario I can think of where everything up to this point would work ok. And even for this case there are protections in gl viewer to not draw into un umapped window … unless X is buggy / confused.

Sigh, sorry for not being able to provide more info. Disabling the guides in the script is still an option (they must be enabled there as default is no guides). And then try enabling them after the window is shown.


Thanks for your effort of looking into this. I turned off the guides in the geom_cms.C example in $ROOTSYS/tutorials/eve, but get the ‘old’ segfault again:

#0  0x00007f246b1b354c in __libc_waitpid (pid=58427, stat_loc=stat_loc
entry=0x7fff7d6e9240, options=options
entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:31
#1  0x00007f246b135232 in do_system (line=<optimised out>) at ../sysdeps/posix/system.c:148
#2  0x00007f246bc9e489 in TUnixSystem::StackTrace (this=0x20e08e0) at /home/ahmad/Desktop/root-vizbugfix/root/core/unix/src/TUnixSystem.cxx:2412
#3  0x00007f246bca013c in TUnixSystem::DispatchSignals (this=0x20e08e0, sig=kSigSegmentationViolation) at /home/ahmad/Desktop/root-vizbugfix/root/core/unix/src/TUnixSystem.cxx:3632
#4  <signal handler called>
#5  strlen () at ../sysdeps/x86_64/strlen.S:106
#6  0x00007f244b8349cc in llvm::MemoryBuffer::getMemBufferRef() const () from /usr/lib/x86_64-linux-gnu/
#7  0x00007f244b310063 in llvm::MCJIT::generateCodeForModule(llvm::Module*) () from /usr/lib/x86_64-linux-gnu/
#8  0x00007f244b30df80 in llvm::MCJIT::finalizeObject() () from /usr/lib/x86_64-linux-gnu/
#9  0x00007f244b173262 in LLVMGetPointerToGlobal () from /usr/lib/x86_64-linux-gnu/
#10 0x00007f244d12bc59 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#11 0x00007f244d12d025 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#12 0x00007f244d064e1f in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#13 0x00007f244d05e04f in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#14 0x00007f244d05e537 in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#15 0x00007f244cf332fd in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#16 0x00007f244cf0409f in ?? () from /usr/lib/x86_64-linux-gnu/dri/
#17 0x00007f245637e16c in TubeMesh::Draw (this=0x8aad6f0) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLCylinder.cxx:326
#18 0x00007f2456380ada in TGLCylinder::DirectDraw (this=<optimised out>, rnrCtx=...) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLCylinder.cxx:652
#19 0x00007f24563c70df in TGLPhysicalShape::Draw (this=0x816e4f0, rnrCtx=...) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLPhysicalShape.cxx:409
#20 0x00007f24563d84e1 in TGLScene::RenderElements (this=<optimised out>, rnrCtx=..., elVec=std::vector of length 8065, capacity 13705 = {...}, check_timeout=true, clipPlanes=0x7fff7d6ece60) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLScene.cxx:919
#21 0x00007f24563d8b5f in TGLScene::RenderAllPasses (this=0x64d2290, rnrCtx=..., elVec=std::vector of length 8065, capacity 13705 = {...}, check_timeout=true) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLScene.cxx:868
#22 0x00007f2456404a61 in TGLViewerBase::SubRenderScenes (this=0x64dee30, render_foo=&virtual table offset 144) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLViewerBase.cxx:411
#23 0x00007f2456404ca4 in TGLViewerBase::RenderOpaque (this=0x64dee30, rnr_non_selected=<optimised out>, rnr_selected=<optimised out>) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLViewerBase.cxx:492
#24 0x00007f2456404377 in TGLViewerBase::Render (this=0x64dee30) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLViewerBase.cxx:425
#25 0x00007f2456403061 in TGLViewer::DoSelect (this=0x64dee20, x=310, y=253) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLViewer.cxx:1345
#26 0x00007f24564032b6 in TGLViewer::RequestSelect (this=<optimised out>, x=<optimised out>, y=<optimised out>) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLViewer.cxx:1316
#27 0x00007f2456382404 in TGLEventHandler::SelectForMouseOver (this=0x64ed5b0) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLEventHandler.cxx:171
#28 0x00007f2456382e28 in TGLEventHandler::HandleTimer (this=<optimised out>, t=<optimised out>) at /home/ahmad/Desktop/root-vizbugfix/root/graf3d/gl/src/TGLEventHandler.cxx:1005
#29 0x00007f246bbffae7 in TTimer::Notify (this=0x64ed690) at /home/ahmad/Desktop/root-vizbugfix/root/core/base/src/TTimer.cxx:146
#30 0x00007f246bbffa41 in TTimer::CheckTimer (this=this
entry=0x64ed690, now=...) at /home/ahmad/Desktop/root-vizbugfix/root/core/base/src/TTimer.cxx:132
#31 0x00007f246bca0089 in TUnixSystem::DispatchTimers (this=this
entry=0x20e08e0, mode=mode
entry=true) at /home/ahmad/Desktop/root-vizbugfix/root/core/unix/src/TUnixSystem.cxx:2957
#32 0x00007f246bca0a00 in TUnixSystem::DispatchOneEvent (this=0x20e08e0, pendingOnly=<optimised out>) at /home/ahmad/Desktop/root-vizbugfix/root/core/unix/src/TUnixSystem.cxx:1095
#33 0x00007f246bbed396 in TSystem::InnerLoop (this=0x20e08e0) at /home/ahmad/Desktop/root-vizbugfix/root/core/base/src/TSystem.cxx:410
#34 0x00007f246bbee000 in TSystem::Run (this=0x20e08e0) at /home/ahmad/Desktop/root-vizbugfix/root/core/base/src/TSystem.cxx:360
#35 0x00007f246bb9235f in TApplication::Run (this=this
entry=0x212de20, retrn=retrn
entry=false) at /home/ahmad/Desktop/root-vizbugfix/root/core/base/src/TApplication.cxx:1153
#36 0x00007f246bfe91e5 in TRint::Run (this=0x212de20, retrn=<optimised out>) at /home/ahmad/Desktop/root-vizbugfix/root/core/rint/src/TRint.cxx:455
#37 0x0000000000400bac in main (argc=1, argv=0x7fff7d6ef3c8) at /home/ahmad/Desktop/root-vizbugfix/root/main/src/rmain.cxx:30

And sometimes it wont segfault into that, and I can pan around the 3D object a bit, until it crashes with the following message:

*** Error in `/home/ahmad/Desktop/root-vizbugfix/root/buildroot/bin/root.exe': free(): invalid pointer: 0x0000000007e90328 ***

If this gets too specific for my use case, then I wouldn’t mind waiting for a my new machine to just run everything natively (instead of a VM).

TGLCylinder.cxx:326 is a call to glDrawArrays … so it gives mesa llvm trouble even when the display lists are not active, well, sooner or later, sigh :slight_smile:

As you say … I’m running out of ideas here … sorry :frowning:

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.