GLXBadContextTag error with XQuartz 2.7.7
Submitted by gen..@..ak.com
Assigned to Jeremy Huddleston Sequoia
Description
Created attachment 119497 Print-out of the old page
I'm copying the bug report from macforge.
One additional note is that on Mac having no external video card like 13-inch MBPR this problem doesn't occur! So, maybe it's related to the graphics driver on Mac. I tried to install webdriver provided by NVidia but it doesn't affect anything.
Thanks for your help!!
Bests
Hello.
I'm using ROOT (root.cern.ch) remotely and it uses X11 forward for showing something.
For some parts of that package, it gives me errors like below.
It was okay with XQuartz 2.7.6, so I think something is wrong with XQuartz 2.7.7.
I can present you much information if you need.
Thank you in advance.
Genie
Error in <RootX11ErrorHandler>: GLXBadContextTag (TGLWidget XID: 6292620, XREQ: 150)
TGLWidget: 6292620
TGVerticalFrame: 6292120
TGLSAFrame: 6292109
TGCompositeFrame: 6292108
TEveCompositeFrameInTab: 6292101
TGCompositeFrame: 6292100
TGTab: 6291588
TGHorizontalFrame: 6291579
TGVerticalFrame: 6291578
TGHorizontalFrame: 6291576
TGVerticalFrame: 6291565
TEveBrowser: 6291564
Error in TGLLockable::TakeLock: 'TGLViewerBase' unable to take DrawLock, already DrawLock
Error in TGLLockable::TakeLock: 'TGLViewerBase' unable to take DrawLock, already DrawLock
Error in TGLLockable::TakeLock: 'TGLViewerBase' unable to take DrawLock, already DrawLock
Error in TGLLockable::TakeLock: 'TGLViewerBase' unable to take DrawLock, already DrawLock
Error in TGLLockable::TakeLock: 'TGLViewerBase' unable to take DrawLock, already DrawLock
Genie
This problem is solved in 2.7.8 beta 1 So, please close this ticket.
Genie
I'm sorry but recently I see the same error. I think the environmental variables are not set with 2.7.8 beta 1 version before. I've rolled back to 2.7.6 to avoid this error.
Jeremy
Please test 2.7.8_beta2 and report if the issue is resolved.
Genie
Thank you for catching up. I'll try soon.
Genie
I tried it and it also gives the same error message. Thank you.
Jeremy
That's odd. I basically reverted the X11 GLX change that went into 2.7.7. Can you help me reproduce this? Assuming I install ROOT on a remote Linux box, how do I use it to trigger the bug?
Genie
Okay. I'll send you the intruction to encounter that error soon.
Genie
Here's the test configuration. OS: Scientific Linux 6.3 ROOT: 5.34.21with gcc 4.4.6 ROOT: 6.02.04 with gcc 4.8.2 You can download both version of ROOT from http://root.cern.ch After you installed it and load environmental variables, type 'root' will let you in to ROOT. At the prompt, typing 'TEveManager::Create()' will cause the error. Thank you very much for your effort to correct this error!
Matevz
Hi, I'm the guy that is mostly responsible for the GL code in ROOT :) I ran latest root-5.34 remotely (on Fedora 20 with latest NVIDIA drivers) against XQuartz-2.7.8_beta3 (on osx-10.8.5, yeah, I'm lazy) and can also still reproduce the problem. I used X in sync mode so I could trace down where this happens, and it's actually in the first call to glXMakeCurrent. From GLX context struct in root: fDpy = 0xf02900, fVisualInfo = 0x1e598e0, fGLContext = 0x1e59df0, fWindowID = 6292698, The XErrorEvent: (gdb) p *err $4 = { type = 0, display = 0xf02900, resourceid = 6292698, serial = 46143, error_code = 164 '\244', request_code = 150 '\226', minor_code = 5 '\005' } (gdb) p msg $6 = "GLXBadContextTag" And this is the place where the context is created for X (we share contexts so we can share display lists and textures but in this case it's the only context created so share = None): https://github.com/root-mirror/root/blob/v5-34-00-patches/graf3d/gl/src/TGLContext.cxx#L335 The code here is if-defed for Win, Cocoa and X ... and you can ignore calls through interpreter (gROOT->ProccessLine(...)), this is really only needed for Windows to get gl code executed in the "main" thread, not GUI one. Please let me know if I can help in any way ... I can set you up an account on a machine with root installed (or help you build root on your machine). Could there be any other changes affecting this? Our code hasn't changed in 4 years ... Best, Matevz
Genie
A friend of mine encountered the same problem with Fedora and he solved the problem by changing to the indirect rendering. I though this is related to the problem we're having with XQuartz. So, I just leave as a note here. /etc/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "Intel Graphics" Driver "intel" Option "DRI" "False" EndSection comment:296
Jeremy
Should be resolved with 2.7.8
Genie
Thank you for the update! Unfortunately, it's not fixed.... Matevz mentioned he can provide test bench for this bug. So, it would be good to contact him for testing this. Thank you for your efforts!
Jeremy
Damn. I was hoping this was the same as another issue. Matevz, can you please attach that test suite? Thanks.
Genie
I just emailed you. That might be a little bit slow but perfectly give you the error.
Matevz
Damn. I was hoping this was the same as another issue. Matevz, can you please attach that test suite? Thanks. I'm away this week, will also give it a try next week. What was the change you thought should fix the problem?
Attachment 119497, "Print-out of the old page":
log.pdf
Version: 2.7.7 (xserver-1.15.2)