[Development] [OS X/xcb] error: xp_attach_gl_context returned: 2 followed by hang during application exit

[René J.V. Bertin]

Hello,

I know there is no official support for using the xcb platform plugin on OS X, but since it builds (without particular hurdles):

The OpenGL examples run on a local X server, despite the fact that the xcb plugin links to both the X11 GL libraries and {OpenGL,AGL}.framework . However, quitting apparently requires closing the window through the window manager, and when I do that I get an error on the calling terminal

error: xp_attach_gl_context returned: 2

the error is apparently printed by apple_glx_make_current_context:

Process 84025 stopped
* thread #1: tid = 0x1cf5578, 0x0000000105743b3a libXplugin.1.dylib`xp_attach_gl_context, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000105743b3a libXplugin.1.dylib`xp_attach_gl_context
libXplugin.1.dylib`xp_attach_gl_context:
-> 0x105743b3a: pushq %rbp
0x105743b3b: movq %rsp, %rbp
0x105743b3e: pushq %r14
0x105743b40: pushq %rbx
(lldb) finish
Process 84025 stopped
* thread #1: tid = 0x1cf5578, 0x00000001053f46c4 libGL.1.dylib`surface_make_current + 93, queue = 'com.apple.main-thread', stop reason = step out
frame #0: 0x00000001053f46c4 libGL.1.dylib`surface_make_current + 93
libGL.1.dylib`surface_make_current + 93:
-> 0x1053f46c4: movl %eax, %ecx
0x1053f46c6: testl %ecx, %ecx
0x1053f46c8: je 0x1053f46eb ; surface_make_current + 132
0x1053f46ca: movq 0x43957(%rip), %rax ; (void *)0x00007fff769367d8: __stderrp
(lldb) finish
error: xp_attach_gl_context returned: 2
Process 84025 stopped
* thread #1: tid = 0x1cf5578, 0x00000001053f2c0b libGL.1.dylib`apple_glx_make_current_context + 706, queue = 'com.apple.main-thread', stop reason = step out
frame #0: 0x00000001053f2c0b libGL.1.dylib`apple_glx_make_current_context + 706
libGL.1.dylib`apple_glx_make_current_context + 706:
-> 0x1053f2c0b: movb $0x1, %r14b
0x1053f2c0e: testb %al, %al
0x1053f2c10: jne 0x1053f2bac ; apple_glx_make_current_context + 611
0x1053f2c12: jmp 0x1053f2a7a ; apple_glx_make_current_context + 305
(lldb) bt
* thread #1: tid = 0x1cf5578, 0x00000001053f2c0b libGL.1.dylib`apple_glx_make_current_context + 706, queue = 'com.apple.main-thread', stop reason = step out
* frame #0: 0x00000001053f2c0b libGL.1.dylib`apple_glx_make_current_context + 706
frame #1: 0x00000001053fbbe4 libGL.1.dylib`applegl_bind_context + 61
frame #2: 0x00000001053f8a53 libGL.1.dylib`MakeContextCurrent + 289
frame #3: 0x00000001052be087 libqxcb.dylib`QGLXContext::makeCurrent(this=0x0000000103531750, surface=0x000000010352fb30) + 103 at qglxintegration.cpp:476
frame #4: 0x000000010093129e QtGui`QOpenGLContext::makeCurrent(this=0x0000000103530240, surface=0x000000010352f5a0) + 174 at qopenglcontext.cpp:896
frame #5: 0x00000001000901a1 QtWidgets`QWidgetPrivate::deleteTLSysExtra(this=0x000000010360dbd0) + 81 at qwidget.cpp:1814
frame #6: 0x000000010008ff5e QtWidgets`QWidget::destroy(this=<unavailable>, destroyWindow=<unavailable>, destroySubWindows=<unavailable>) + 1022 at qwidget.cpp:12202
frame #7: 0x000000010008f617 QtWidgets`QWidget::~QWidget(this=0x00007fff5fbfee20) + 1639 at qwidget.cpp:1647
frame #8: 0x0000000100003fd7 textures`main + 119
frame #9: 0x00007fff9158f5fd libdyld.dylib`start + 1

When I let the application continue, it will eventually hang:
(lldb) c
Process 84025 resuming
Process 84025 stopped
* thread #1: tid = 0x1cf5578, 0x00007fff869d4746 libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0x00007fff869d4746 libsystem_kernel.dylib`__psynch_mutexwait + 10
libsystem_kernel.dylib`__psynch_mutexwait + 10:
-> 0x7fff869d4746: jae 0x7fff869d4750 ; __psynch_mutexwait + 20
0x7fff869d4748: movq %rax, %rdi
0x7fff869d474b: jmp 0x7fff869d1175 ; cerror_nocancel
0x7fff869d4750: retq
(lldb) c
Process 84025 resuming
Process 84025 stopped
* thread #1: tid = 0x1cf5578, 0x00007fff869d4746 libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0x00007fff869d4746 libsystem_kernel.dylib`__psynch_mutexwait + 10
libsystem_kernel.dylib`__psynch_mutexwait + 10:
-> 0x7fff869d4746: jae 0x7fff869d4750 ; __psynch_mutexwait + 20
0x7fff869d4748: movq %rax, %rdi
0x7fff869d474b: jmp 0x7fff869d1175 ; cerror_nocancel
0x7fff869d4750: retq
(lldb) bt
* thread #1: tid = 0x1cf5578, 0x00007fff869d4746 libsystem_kernel.dylib`__psynch_mutexwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* frame #0: 0x00007fff869d4746 libsystem_kernel.dylib`__psynch_mutexwait + 10
frame #1: 0x00007fff87c53779 libsystem_pthread.dylib`_pthread_mutex_lock + 372
frame #2: 0x0000000107e84e74 libX11.6.dylib`_XLockDisplay + 24
frame #3: 0x00000001053f73cd libGL.1.dylib`glXDestroyContext + 87
frame #4: 0x00000001052bdf46 libqxcb.dylib`QGLXContext::~QGLXContext() [inlined] QGLXContext::~QGLXContext(this=0x0000000103531750) + 29 at qglxintegration.cpp:446
frame #5: 0x00000001052bdf29 libqxcb.dylib`QGLXContext::~QGLXContext() [inlined] QGLXContext::~QGLXContext(this=0x0000000103531750) at qglxintegration.cpp:444
frame #6: 0x00000001052bdf29 libqxcb.dylib`QGLXContext::~QGLXContext(this=0x0000000103531750) + 9 at qglxintegration.cpp:444
frame #7: 0x0000000100930546 QtGui`QOpenGLContext::destroy(this=<unavailable>) + 310 at qopenglcontext.cpp:634
frame #8: 0x0000000100930b8c QtGui`QOpenGLContext::~QOpenGLContext() [inlined] QOpenGLContext::~QOpenGLContext(this=0x0000000103530240) + 19 at qopenglcontext.cpp:666
frame #9: 0x0000000100930b79 QtGui`QOpenGLContext::~QOpenGLContext() [inlined] QOpenGLContext::~QOpenGLContext(this=0x0000000103530240) at qopenglcontext.cpp:665
frame #10: 0x0000000100930b79 QtGui`QOpenGLContext::~QOpenGLContext(this=0x0000000103530240) + 9 at qopenglcontext.cpp:665
frame #11: 0x0000000100090266 QtWidgets`QWidgetPrivate::deleteTLSysExtra(this=0x000000010360dbd0) + 278 at qwidget.cpp:1822
frame #12: 0x000000010008ff5e QtWidgets`QWidget::destroy(this=<unavailable>, destroyWindow=<unavailable>, destroySubWindows=<unavailable>) + 1022 at qwidget.cpp:12202
frame #13: 0x000000010008f617 QtWidgets`QWidget::~QWidget(this=0x00007fff5fbfee20) + 1639 at qwidget.cpp:1647
frame #14: 0x0000000100003fd7 textures`main + 119
frame #15: 0x00007fff9158f5fd libdyld.dylib`start + 1

It'd be easy to chalk this off to a bug in libX11 and/or Mesa, but maybe the Qt code isn't without blame either? Where could I look for relevant code paths that are not identical on OS X and Unix/X11/xcb ?
FWIW, the "host" Qt install is built normally for OS X; the xcb plugin is created by building qtbase once more with the relevant options set (and only the xcb platform and platforminput plugins are then installed to the Qt plugins directory). The examples are built normally.


Thanks,
R.

[René J.V. Bertin]

On Sunday March 29 2015 11:57:16 Jeremy Huddleston Sequoia wrote:

> > The OpenGL examples run on a local X server, despite the fact that the xcb plugin links to both the X11 GL libraries and {OpenGL,AGL}.framework .
>
> Yeah, you should drop those other links. Hopefully the libGL link is at least first. Most of the gl* function calls in the mesa libGL just forward on to OpenGL.framework, but there are a few that don't.

I can try (once more) to see if it changes anything if I drop those links, but the list currently seems to have an appropriate order:

%> otool -L /opt/local/share/qt5/plugins/platforms/libqxcb.dylib
/opt/local/share/qt5/plugins/platforms/libqxcb.dylib:
libqxcb.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/local/lib/libX11-xcb.1.dylib (compatibility version 2.0.0, current version 2.0.0)
/opt/local/lib/libXi.6.dylib (compatibility version 8.0.0, current version 8.0.0)
/opt/local/lib/libGL.1.dylib (compatibility version 1.2.0, current version 1.2.0)
/opt/local/lib/libxcb-render-util.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libSM.6.dylib (compatibility version 7.0.0, current version 7.1.0)
/opt/local/lib/libICE.6.dylib (compatibility version 10.0.0, current version 10.0.0)
/opt/local/lib/libxcb-glx.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libxcb-render.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libxcb.1.dylib (compatibility version 3.0.0, current version 3.0.0)
/opt/local/lib/libxcb-image.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libxcb-icccm.4.dylib (compatibility version 5.0.0, current version 5.0.0)
/opt/local/lib/libxcb-sync.1.dylib (compatibility version 2.0.0, current version 2.0.0)
/opt/local/lib/libxcb-xfixes.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libxcb-shm.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libxcb-randr.0.dylib (compatibility version 2.0.0, current version 2.0.0)
/opt/local/lib/libxcb-shape.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libxcb-keysyms.1.dylib (compatibility version 2.0.0, current version 2.0.0)
/opt/local/lib/libxcb-xkb.1.dylib (compatibility version 2.0.0, current version 2.0.0)
/opt/local/lib/libfontconfig.1.dylib (compatibility version 10.0.0, current version 10.0.0)
/opt/local/lib/libfreetype.6.dylib (compatibility version 18.0.0, current version 18.4.0)
/opt/local/libexec/qt5/Library/Frameworks/QtGui.framework/Versions/5/QtGui (compatibility version 5.4.0, current version 5.4.1)
/opt/local/libexec/qt5/Library/Frameworks/QtCore.framework/Versions/5/QtCore (compatibility version 5.4.0, current version 5.4.1)
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/opt/local/libexec/qt5/Library/Frameworks/QtDBus.framework/Versions/5/QtDBus (compatibility version 5.4.0, current version 5.4.1)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libgthread-2.0.0.dylib (compatibility version 4201.0.0, current version 4201.1.0)
/opt/local/lib/libglib-2.0.0.dylib (compatibility version 4201.0.0, current version 4201.1.0)
/opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.3.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0)
/opt/local/lib/libXrender.1.dylib (compatibility version 5.0.0, current version 5.0.0)
/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
/opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

But that would just be the xcb plugin. The host applications will still be linked against {OpenGL,AGL}.framework, at least as long as I just build the xcb platform plugin as an alternative for a Qt install that uses Cocoa by (and as the supported) default.

> BTW, assuming you're using XQuartz, we provide the dSYMS. Eg:
> http://xquartz-dl.macosforge.org/SL/XQuartz-2.7.8_rc1.dSYMS.tar.bz2

That's good to know, thanks.

> I suspect this is http://xquartz.macosforge.org/trac/ticket/420

That does seem relevant indeed.

> No, it's almost certainly the XQuartz-specific GLX bits in mesa that haven't had much attention in 6+ years.

The fact that there's a BadValue error is unlikely to be Qt's doing, nor the deadlock in XLockDisplay. But is there nothing Qt applications could or should do to handle the window-close event in such a way that the issue is avoided?

> Note that we need a few patches to get things working:
> http://trac.macports.org/browser/trunk/dports/x11/mesa/files

I'll see if installing the latest port:mesa changes anything.

R.

[René J.V. Bertin]

On Sunday March 29 2015 14:15:20 Jeremy Huddleston Sequoia wrote:

> You can run 'nm -m /opt/local/share/qt5/plugins/platforms/libqxcb.dylib | grep OpenGL' to see if there is anything actually using the OpenGL.framework link. However, this linking is certainly not the source of your problems.

It's not like that doesn't produce any output, but judging from the mangled names they're all Qt functions (OpenGL.framework is written in C I presume?)

> > But that would just be the xcb plugin. The host applications will still be linked against {OpenGL,AGL}.framework, at least as long as I just build the xcb platform plugin as an alternative for a Qt install that uses Cocoa by (and as the supported) default.
>
> Then that's a bug in how the application is linking and would need to be fixed there as well.

Erm, no, I wouldn't call that a bug in the linking. It's more that Qt5's platform plugin architecture apparently hasn't been conceived to support platforms that use/require different OpenGL libraries. For that to work Qt would either have to encapsulate all OpenGL functions in the platform plugin, or load the libraries dynamically.

R.

[Agocs Laszlo]

That has nothing to do with the platform plugins. You will want to introduce your own makespecs, or at least start customizing the standard Mac one. See e.g. mkspecs/common/mac.conf. That's what pulls in the standard GL frameworks for both the Qt libs and the app makefiles generated by qmake.

Best regards,
Laszlo

________________________________________
From: development-bounces+laszlo.agocs=***@qt-project.org <development-bounces+laszlo.agocs=***@qt-project.org> on behalf of René J.V. Bertin <***@gmail.com>
Sent: Monday, March 30, 2015 12:03 AM
To: Jeremy Huddleston Sequoia
Cc: Apple X11 Users' List; <***@qt-project.org>
Subject: Re: [Development] [OS X/xcb] error: xp_attach_gl_context returned: 2 followed by hang during application exit

On Sunday March 29 2015 14:15:20 Jeremy Huddleston Sequoia wrote:

> You can run 'nm -m /opt/local/share/qt5/plugins/platforms/libqxcb.dylib | grep OpenGL' to see if there is anything actually using the OpenGL.framework link. However, this linking is certainly not the source of your problems.

It's not like that doesn't produce any output, but judging from the mangled names they're all Qt functions (OpenGL.framework is written in C I presume?)

> > But that would just be the xcb plugin. The host applications will still be linked against {OpenGL,AGL}.framework, at least as long as I just build the xcb platform plugin as an alternative for a Qt install that uses Cocoa by (and as the supported) default.
>
> Then that's a bug in how the application is linking and would need to be fixed there as well.

Erm, no, I wouldn't call that a bug in the linking. It's more that Qt5's platform plugin architecture apparently hasn't been conceived to support platforms that use/require different OpenGL libraries. For that to work Qt would either have to encapsulate all OpenGL functions in the platform plugin, or load the libraries dynamically.

R.

[René J.V. Bertin]

On Monday March 30 2015 08:15:09 Agocs Laszlo wrote:

Hi,

>That has nothing to do with the platform plugins. You will want to introduce your own makespecs, or at least start customizing the standard Mac one. See e.g. mkspecs/common/mac.conf. That's what pulls in the standard GL frameworks for both the Qt libs and the app makefiles generated by qmake.

I would argue that it depends on how the platform plugins are supposed to be used/usable. If the idea is that the user can load a different plugin in application X to have it render using a different platform, then yes, it has to do with the plugins and no, you cannot just rewrite the mkspec to cat for something linking to a different OpenGL library at runtime.

If the plugins are not supposed to be used like that (despite the -platform commandline option), then yes, I can patch mac.conf so that it references the correct OpenGL libraries. I haven't checked, but I have a hunch that I'd have to build all of Qt like that.

In the meantime, it does seem that things work well enough with the approach followed. The palette looks odd (MSWindows 95 like?) but apart from that and the reported hang-on-exit I think that there's enough basic functionality for routine testing for instance.
It'll also give a nice tool to assess memory footprint (would it be smaller under X11) etc.

And of course text renders much better using Freetype/Fontconfig with the Infinality-Ultimate patches than using CoreText O:-)

R.

[Agocs Laszlo]

The OpenGL libs (and potentially a number of other system libs) are not supposed to be runtime switchable. The exception is Windows, where Qt 5.4 introduced fully dynamic resolving for WGL/EGL/GL/GLES in the platform plugin. Other platforms may get similar features in the future, but OS X is unlikely to be one of them. Therefore the OS X makespecs will continue to pull in the GL frameworks in the foreseeable future.

Cheers,
Laszlo

________________________________________
From: development-bounces+laszlo.agocs=***@qt-project.org <development-bounces+laszlo.agocs=***@qt-project.org> on behalf of René J.V. Bertin <***@gmail.com>
Sent: Monday, March 30, 2015 10:42 AM
Cc: Apple X11 Users' List; <***@qt-project.org>
Subject: Re: [Development] [OS X/xcb] error: xp_attach_gl_context returned: 2 followed by hang during application exit

On Monday March 30 2015 08:15:09 Agocs Laszlo wrote:

Hi,

>That has nothing to do with the platform plugins. You will want to introduce your own makespecs, or at least start customizing the standard Mac one. See e.g. mkspecs/common/mac.conf. That's what pulls in the standard GL frameworks for both the Qt libs and the app makefiles generated by qmake.

I would argue that it depends on how the platform plugins are supposed to be used/usable. If the idea is that the user can load a different plugin in application X to have it render using a different platform, then yes, it has to do with the plugins and no, you cannot just rewrite the mkspec to cat for something linking to a different OpenGL library at runtime.

If the plugins are not supposed to be used like that (despite the -platform commandline option), then yes, I can patch mac.conf so that it references the correct OpenGL libraries. I haven't checked, but I have a hunch that I'd have to build all of Qt like that.

In the meantime, it does seem that things work well enough with the approach followed. The palette looks odd (MSWindows 95 like?) but apart from that and the reported hang-on-exit I think that there's enough basic functionality for routine testing for instance.
It'll also give a nice tool to assess memory footprint (would it be smaller under X11) etc.

And of course text renders much better using Freetype/Fontconfig with the Infinality-Ultimate patches than using CoreText O:-)

R.

[René J.V. Bertin]

On Monday March 30 2015 08:54:48 Agocs Laszlo wrote:
>The OpenGL libs (and potentially a number of other system libs) are not supposed to be runtime switchable. The exception is Windows, where Qt 5.4 introduced fully dynamic resolving for WGL/EGL/GL/GLES in the platform plugin.

More or less like what GLEW does to encapsulate OpenGL (or was that another project, it's been a while I manhandled OpenGL...)? Such an approach shouldn't be (too) platform-dependent, and thus relatively straightforward to bring to other platforms, no?

>Other platforms may get similar features in the future, but OS X is unlikely to be one of them. Therefore the OS X makespecs will continue to pull in the GL frameworks in the foreseeable future.

I wasn't expecting anything else.

But:

FWIW, I think there might be interest in bringing X11/xcb support back to OS X, which could justify bringing those "similar features" on to OS X too. I'm not volunteering though (but wouldn't mind being paid for doing this either ;)).