Skip to content
This repository has been archived by the owner. It is now read-only.
Permalink
master
Switch branches/tags
Go to file
 
 
Cannot retrieve contributors at this time
original_url created_at updated_at closed_at status type resolution reporter owner priority milestone component version cc
2014-10-24 20:16:23 -0700
2015-11-09 09:43:01 -0800
2015-11-09 09:43:01 -0800
closed
crash
Duplicate
geniejhang@…
jeremyhu@…
Important
2.7.9
GLX
2.7.7 (xserver-1.15.2)
geniejhang@…

GLXBadContextTag error with XQuartz 2.7.7

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


geniejhang@… commented on Oct 29, 2014

  • Cc geniejhang@… added

geniejhang@… commented on Dec 10, 2014

This problem is solved in 2.7.8 beta 1 So, please close this ticket.


jeremyhu@… commented on Dec 10, 2014

  • Status changed from new to closed
  • Milestone set to 2.7.8
  • Resolution set to Fixed

geniejhang@… commented on Dec 17, 2014

  • Status changed from closed to reopened
  • Resolution Fixed deleted

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.


jeremyhu@… commented on Feb 15, 2015

Please test 2.7.8_beta2 and report if the issue is resolved.


geniejhang@… commented on Feb 15, 2015

Thank you for catching up. I'll try soon.


geniejhang@… commented on Feb 15, 2015

I tried it and it also gives the same error message.

Thank you.


jeremyhu@… commented on Feb 15, 2015

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?


geniejhang@… commented on Feb 15, 2015

Okay. I'll send you the intruction to encounter that error soon.


geniejhang@… commented on Feb 15, 2015

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!


mtadel@… commented on Feb 26, 2015

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


jeremyhu@… commented on Mar 25, 2015

  • Status changed from reopened to new
  • Milestone changed from 2.7.8 to 2.7.9

geniejhang@… commented on Jul 28, 2015

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


jeremyhu@… commented on Oct 17, 2015

  • Status changed from new to closed
  • Milestone changed from 2.7.9 to 2.7.8
  • Resolution set to Fixed

Should be resolved with 2.7.8


geniejhang@… commented on Oct 17, 2015

  • Status changed from closed to reopened
  • Resolution Fixed deleted

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!


jeremyhu@… commented on Oct 17, 2015

  • Milestone changed from 2.7.8 to 2.7.9

Damn. I was hoping this was the same as another issue.

Matevz, can you please attach that test suite? Thanks.


jeremyhu@… commented on Oct 17, 2015

  • Status changed from reopened to new

jeremyhu@… commented on Oct 17, 2015

  • Status changed from new to assigned

geniejhang@… commented on Oct 17, 2015

I just emailed you. That might be a little bit slow but perfectly give you the error.


mtadel@… commented on Oct 20, 2015

Replying to jeremyhu@…:

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?


jeremyhu@… commented on Oct 23, 2015

Mass Edit

As you may have noticed, we have had issues with spam in trac for the past couple years. We've decided to migrate to using freedesktop.org's bugzilla for our bug tracker (more details will be coming on the mailing lists in the next couple weeks).

I don't want us to loose valuable bug reports in the transition, so I want to make sure that any relevant open issues in this MacOSForge trac are migrated over to the new system. If you are interested in this issue, please take a few minutes to file a new bug for this issue in bugzilla. Please make sure to do the following:

  • Copy over all relevant information into that report, just in case we loose this one.
  • Set the URL field of the bugzilla report to this trac ticket's URL.
  • Paste the URL of the new bugzilla report as a comment in this ticket, and I'll close it out.

jeremyhu@… commented on Nov 9, 2015

  • Status changed from assigned to closed
  • Resolution set to Duplicate

https://bugs.freedesktop.org/show_bug.cgi?id=92868