XQuartz takes time when running glxinfo

[xquartz@…]

If I run time glxinfo with XQuartz 2.7.2 RC1, it takes more than 5 seconds

It's not an important problem at all, but sometimes, I need to use glxinfo in scripts to check stuffs like direct rendering and it make the script run slower

This problem didn't exit in the latest beta

[xquartz@…]

Cc Me!

[jeremyhu@…]

Was X11 running when you ran glxinfo? It responds immediately for me. Can you take a spindump when it's in this stuck state?

[xquartz@…]

Ok, I've discovered that I had /usr/X11/bin in my PATH, so the problem happens when you run:

/usr/X11/bin/glxinfo

(I have OSX 10.7) Consequently, I'm not sure that it's a XQuartz bug, but the problem did not occur in 2.7.2 beta 2

[jeremyhu@…]

Can you please be more explicit about the problem? It's expected that glxinfo will take a while to print information if the server needs to start to respond to it. If the server is running, it should respond immediately. It doesn't matter which version of glxinfo you use.

[xquartz@…]

Yes sorry,

So XQuartz is already running.

I open Terminal.app, and I type

• time /usr/X11/bin/glxinfo

I takes about 5 seconds : real 0m5.106s

[xquartz@…]

Spindump

[xquartz@…]

glxinfo output + Output written when it's in a suck state

[jeremyhu@…]

It looks like you edited away a good portion of the spindump. From what you provided, I can tell that it's waiting for a reply from the server ... but you edited out what the server was doing, so I can't really tell any more.

Please attach the complete spindump.

[xquartz@…]

By the way, the problem does not appear if I run /opt/X11/bin/glxinfo

[jeremyhu@…]

  Thread 0x26cd9     
  User stack:
    511 thread_start + 13 (in libsystem_c.dylib) [0x7fff8ab1bb75]
      511 _pthread_start + 335 (in libsystem_c.dylib) [0x7fff8ab188bf]
        511 server_thread + 38 (in X11.bin) [0x100011807]
          511 dix_main + 185 (in X11.bin) [0x100026e6e]
            499 Dispatch + 257 (in X11.bin) [0x1000be15b]
              499 ProcAppleDRICreateSurface + 177 (in X11.bin) [0x1000136e1]
                499 DRICreateSurface + 708 (in X11.bin) [0x100014631]
                  499 xp_export_surface + 574 (in libXplugin.1.dylib) [0x100256fbf]
                    499 semaphore_timedwait_trap + 10 (in libsystem_kernel.dylib) [0x7fff8df4c6ce]
            12 Dispatch + 568 (in X11.bin) [0x1000be292]
              12 __select + 10 (in libsystem_kernel.dylib) [0x7fff8df4ddf2]

Possibly an issue with the new libXplugin versus the old libXplugin surface exporting...

[jeremyhu@…]

Yeah, this isn't going to change. It's a small delay when using GLX clients that use the legacy libXplugin. There's not really much we can do because we can't tell that they're "old" until we wait for them to timeout to our request.

Behaves unfortunately is probably a better resolution than behaves correctly...