libGL.1.2.dylib shipped with 2.3.3 RC5 makes applications crash
Hello
Changed 3 hours ago by jeremyhu@… • status changed from new to closed • resolution set to worksforme Please bring this up on xquartz-dev for faster iteration and more eyes.
As required, I am bringing this to the developer list. Please find below my original report and attachment.
This bug report is vague and I can't really do anything about it without specifics.
Yes, that's right and I am aware of it. Unfortunately, I am not acquainted at all with XQuartz.
Please give me examples of applications that fail with the new libGL.
(OK, but let's postpone this a bit longer)
mplayer is not a good example as it's not using GLX. It's using OpenGL.framework directly.
Well, that cannot be, because as I link /usr/X11/lib/libGL.1.2.dylib to the new (resp old) dylib mplayer keeps crashing (resp works just fine). I suppose the key here is to run mplayer -vo macosx (as eg mplayer -vo x11 works). Have you tried that? This activates vo_macosx.m which uses libGL, eg: "nm -a vo_macosx.o" list includes:
U _glBegin U _glBindTexture U _glClear U _glColor3f U _glColor4f U _glDepthMask U _glDisable U _glEnable U _glEnd U _glFlush U _glLoadIdentity U _glMatrixMode U _glOrtho U _glTexCoord2f U _glVertex2i U _glViewport
Can it be that the dylib system get confused with different versions of libGL.1.2? I have just noticed something which is likely to be significant: the old libGL (the one which works) appears to link a libGL.dylib v1.0 from the OpenGL framework, while the new libGL, doesnt:
$ otool -L /usr/X11/lib/libGL.1.2.dylib.new /usr/X11/lib/libGL.1.2.dylib.new: /usr/X11/lib/libGL.1.dylib (compatibility version 1.2.0, current version 1.2.0) /usr/lib/libXplugin.1.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ ApplicationServices (compatibility version 1.0.0, current version 34.0.0) /usr/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0) /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3) $ $ otool -L /usr/X11/lib/libGL.1.2.dylib.old /usr/X11/lib/libGL.1.2.dylib.old: /usr/X11/lib/libGL.1.dylib (compatibility version 1.2.0, current version 1.2.0) /usr/lib/libXplugin.1.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGL.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ ApplicationServices (compatibility version 1.0.0, current version 34.0.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /usr/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0) /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3)
Regards, -vmrsss Begin forwarded message:
From: "XQuartz" <trac@macosforge.org> Date: 22 April 2009 21:51:02 BST To: undisclosed-recipients:; Subject: [XQuartz] #259: libGL.1.2.dylib shipped with 2.3.3 RC5 makes applications crash Reply-To: noreply@macosforge.org
#259: libGL.1.2.dylib shipped with 2.3.3 RC5 makes applications crash ------------------------------ +--------------------------------------------- Reporter: vmrsss@… | Owner: jeremyhu@… Type: crash | Status: new Priority: major | Milestone: 2.3.3 Component: x11-libs | Version: dev (xorg-server-1.4- apple) Keywords: | ------------------------------ +--------------------------------------------- Hello. I am unsure whether to raise a ticket or email xquartz-dev, as I don't know that the one I am reporting is a bug. Please bear with me.
Is X11-2.3.3 supposed to be backward compatible? I have installed it, and found that a number of applications which use /usr/X11/lib/libGL. 1.dylib crash. I have also verified that replacing libGL.1.2.dylib with the corresponding file from X11-2.3.2.1, the applications seem to run well again (incidentally, I found strange that the two version of the library are very different in size: 2.3M for 2.3.2.1, against 798K for 2.3.3).
Is this expected? I wouldn't think so, or there would at least have been a bump version number of GL. So, is it a bug to be fixed in X11-2.3.3?
I attach below the output of GDB in the case of one crash (of the open- source application mplayer). I don't think it is particularly useful, it doesn't am happy to help debug, but I need to be instructed about what information/tests you may need.
Question: is it safe to downgrade to 2.3.2.1 by simply installing X11-2.3.2.1 on top of 2.3.3.RC5, or should I remove /usr/X11 entirely before reinstalling? Thx
On Apr 22, 2009, at 18:17, vmrsss wrote:
Hello
Changed 3 hours ago by jeremyhu@… • status changed from new to closed • resolution set to worksforme Please bring this up on xquartz-dev for faster iteration and more eyes.
As required, I am bringing this to the developer list. Please find below my original report and attachment.
This bug report is vague and I can't really do anything about it without specifics.
Yes, that's right and I am aware of it. Unfortunately, I am not acquainted at all with XQuartz.
Please give me examples of applications that fail with the new libGL.
(OK, but let's postpone this a bit longer)
mplayer is not a good example as it's not using GLX. It's using OpenGL.framework directly.
Well, that cannot be, because as I link /usr/X11/lib/libGL.1.2.dylib to the new (resp old) dylib mplayer keeps crashing (resp works just fine)
The stack trace you provided for the mplayer crash clearly shows that it is not using the glx video output plugin. You may have built mplayer with glx support, but you're not using it when this crash happens.
I suppose the key here is to run
mplayer -vo macosx
That is what you're doing. That causes mplayer to not use glx.
(as eg mplayer -vo x11 works). Have you tried that? This activates vo_macosx.m which uses libGL, eg: "nm -a vo_macosx.o" list includes:
U _glBegin U _glBindTexture U _glClear U _glColor3f U _glColor4f U _glDepthMask U _glDisable U _glEnable U _glEnd U _glFlush U _glLoadIdentity U _glMatrixMode U _glOrtho U _glTexCoord2f U _glVertex2i U _glViewport
That's using GL, but it's not using GLX. The macosx output plugin for mplayer uses Cocoa. It has nothing to do with GLX. If you're linking the macosx vo plugin against /usr/X11/lib/libGL.dylib, then you should expect it to not work. The fact that it used to work was pure luck on your part. You want to do -fw OpenGL to link against the correct libGL... not -lGL.
Can it be that the dylib system get confused with different versions of libGL.1.2? I have just noticed something which is likely to be significant: the old libGL (the one which works) appears to link a libGL.dylib v1.0 from the OpenGL framework, while the new libGL, doesnt:
That's correct. We now dlopen() it instead. Can you please provide a specific instance of a GLX application that works with the old libGL but crashes with the new one?
On 23 Apr 2009, at 03:42, Jeremy Huddleston wrote:
That's using GL, but it's not using GLX. The macosx output plugin for mplayer uses Cocoa. It has nothing to do with GLX.
You're right about Cocoa of course.
If you're linking the macosx vo plugin against /usr/X11/lib/ libGL.dylib, then you should expect it to not work. The fact that it used to work was pure luck on your part. You want to do -fw OpenGL to link against the correct libGL... not -lGL.
So, /usr/X11/libGL.dylib contains GLX and /System/Library/..../OpenGL/ Libraries/libGL.dylib contains GL (as used by Cocoa)? I am confused, can you conjecture why if I replace the new libGL.dylib with the one from 2.3.2.1 it all works? OK, luck, but there must be a technical explanation too. I suppose the system loads /usr/X11/lib/libGL.dylib in both cases, does it not? (Also, it's not me who do -lGL, but a complex configure system. In fact, the gcc commandline contains both -fw OpenGL and -lGL. And you're telling me that -lGL should not be there at all... I'll try to find out and see what happens if I remove -lGL.)
Can you please provide a specific instance of a GLX application that works with the old libGL but crashes with the new one?
At this stage I dont know how to tell apart GLX applications from applications which use Cocoa/OpenGL (but possibly load /usr/X11/lib/ libGL.dylib): what I had done previously was to scan my disc for applications which load /usr/X11/lib/libGL.dylib (to check which ones worked and which did not). For instance I had found the crash attached, which now looks to me exactly identical to the one we are discussing. So I wonder, do I have any GLX application at all?
On Apr 22, 2009, at 20:35, vmrsss wrote:
On 23 Apr 2009, at 03:42, Jeremy Huddleston wrote:
That's using GL, but it's not using GLX. The macosx output plugin for mplayer uses Cocoa. It has nothing to do with GLX.
You're right about Cocoa of course.
If you're linking the macosx vo plugin against /usr/X11/lib/ libGL.dylib, then you should expect it to not work. The fact that it used to work was pure luck on your part. You want to do -fw OpenGL to link against the correct libGL... not -lGL.
So, /usr/X11/libGL.dylib contains GLX and /System/Library/..../ OpenGL/Libraries/libGL.dylib contains GL (as used by Cocoa)?
Not exactly. Both are "GL" ... /System/Library/Frameworks/ OpenGL.framework/Libraries/libGL.dylib is CGL. Our GLX libGL is a translation layer that translates GLX to CGL.
I am confused, can you conjecture why if I replace the new libGL.dylib with the one from 2.3.2.1 it all works?
Because of the way we used to implement libGL, it worked for you. You were calling GL functions that were passed directly on to CGL by the old GLX libGL, so you just got lucky that we implemented it that way.
OK, luck, but there must be a technical explanation too. I suppose the system loads /usr/X11/lib/libGL.dylib in both cases, does it not?
It does, because you linked it that way, but the problem is that it shouldn't be linking against the GLX libGL because you are not using GLX. You are using CGL. You need to link against the correct library for it to work correctly (-fw OpenGL rather than -lGL).
(Also, it's not me who do -lGL, but a complex configure system. In fact, the gcc commandline contains both -fw OpenGL and -lGL. And you're telling me that -lGL should not be there at all... I'll try to find out and see what happens if I remove -lGL.)
That is correct.
Can you please provide a specific instance of a GLX application that works with the old libGL but crashes with the new one?
At this stage I dont know how to tell apart GLX applications from applications which use Cocoa/OpenGL (but possibly load /usr/X11/lib/ libGL.dylib): what I had done previously was to scan my disc for applications which load /usr/X11/lib/libGL.dylib (to check which ones worked and which did not). For instance I had found the crash attached, which now looks to me exactly identical to the one we are discussing. So I wonder, do I have any GLX application at all?
Well, one way to know is if it uses X11 or not. When you open the application and the window is in the foreground, is X11 the active OSX application? For instance, if I run mplayer, it will create a separate application in the dock for mplayer. If I use '-vo x11', it will render through X11. --Jeremy
I am confused, can you conjecture why if I replace the new libGL.dylib with the one from 2.3.2.1 it all works?
Because of the way we used to implement libGL, it worked for you. You were calling GL functions that were passed directly on to CGL by the old GLX libGL, so you just got lucky that we implemented it that way.
Thanks folks, I now understand.
PS. If I remove -lGL, linking fails because of
Undefined symbols: "_glXChooseVisual", referenced from: _config in vo_gl.o "_glXCreateContext", referenced from: _setGlWindow in gl_common.o "_glXGetConfig", referenced from: _initGl in vo_gl2.o _initGl in vo_gl2.o _initGl in vo_gl2.o _initGl in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o "_glXSwapBuffers", referenced from: _swapGlBuffers in gl_common.o "_glXDestroyContext", referenced from: _releaseGlContext in gl_common.o _setGlWindow in gl_common.o _setGlWindow in gl_common.o "_glXMakeCurrent", referenced from: _releaseGlContext in gl_common.o _setGlWindow in gl_common.o
which are not in /System/Library/Frameworks/OpenGL.framework/Libraries/ libGL.dylib nor in OpenGL, apparently. (Sorry for being so ignorant about all this...)
Then the problem is much deeper in that it's trying to mix GLX and CGL at the same time. My guess is that this is a complicated and incorrect set of #ifdefs... many applications have such problems, and I've been working with upstream developers to get them fixed as I've run into them. mplayer should have two output plugins for gl. One is macosx which should be linked with '-fw OpenGL'; the other is glx which should be linked with -lGL. The fact that glXDestroyContext is referenced from a file called gl_common.c scares me because it seems that their "common GL" code actually isn't GL at all but GLX. This is definitely an mplayer bug, so please file this issue upstream, and let me know the URL to the bug, so I can follow up with those developers. On Apr 22, 2009, at 20:49, vmrsss wrote:
PS. If I remove -lGL, linking fails because of
Undefined symbols: "_glXChooseVisual", referenced from: _config in vo_gl.o "_glXCreateContext", referenced from: _setGlWindow in gl_common.o "_glXGetConfig", referenced from: _initGl in vo_gl2.o _initGl in vo_gl2.o _initGl in vo_gl2.o _initGl in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o "_glXSwapBuffers", referenced from: _swapGlBuffers in gl_common.o "_glXDestroyContext", referenced from: _releaseGlContext in gl_common.o _setGlWindow in gl_common.o _setGlWindow in gl_common.o "_glXMakeCurrent", referenced from: _releaseGlContext in gl_common.o _setGlWindow in gl_common.o
which are not in /System/Library/Frameworks/OpenGL.framework/ Libraries/libGL.dylib nor in OpenGL, apparently. (Sorry for being so ignorant about all this...) _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
So... I looked at the mplayer source... The mplayer build system is fubar, and I don't want to try fixing it. They're using a common set of ldflags for everything indiscriminately. gl_common.c is for GLX and is used for vo_gl and vo_gl2. vo_macosx.m is for vo_macosx. The former needs -lGL with no -fw OpenGL, the latter needs -fw OpenGL with no -lGL. Feel free to send this info upstream and give me a bug number to follow, but their build system is not clean enough for me to want to try patching. On Apr 22, 2009, at 20:59, Jeremy Huddleston wrote:
Then the problem is much deeper in that it's trying to mix GLX and CGL at the same time. My guess is that this is a complicated and incorrect set of #ifdefs... many applications have such problems, and I've been working with upstream developers to get them fixed as I've run into them.
mplayer should have two output plugins for gl. One is macosx which should be linked with '-fw OpenGL'; the other is glx which should be linked with -lGL.
The fact that glXDestroyContext is referenced from a file called gl_common.c scares me because it seems that their "common GL" code actually isn't GL at all but GLX. This is definitely an mplayer bug, so please file this issue upstream, and let me know the URL to the bug, so I can follow up with those developers.
On Apr 22, 2009, at 20:49, vmrsss wrote:
PS. If I remove -lGL, linking fails because of
Undefined symbols: "_glXChooseVisual", referenced from: _config in vo_gl.o "_glXCreateContext", referenced from: _setGlWindow in gl_common.o "_glXGetConfig", referenced from: _initGl in vo_gl2.o _initGl in vo_gl2.o _initGl in vo_gl2.o _initGl in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o "_glXSwapBuffers", referenced from: _swapGlBuffers in gl_common.o "_glXDestroyContext", referenced from: _releaseGlContext in gl_common.o _setGlWindow in gl_common.o _setGlWindow in gl_common.o "_glXMakeCurrent", referenced from: _releaseGlContext in gl_common.o _setGlWindow in gl_common.o
which are not in /System/Library/Frameworks/OpenGL.framework/ Libraries/libGL.dylib nor in OpenGL, apparently. (Sorry for being so ignorant about all this...) _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
The problem is deeper than I though... It looks like mplayer doesn't use a plugin model for the different input/output/codecs... they link everything into one binary... glx and cgl can't exist in the same namespace. Your only option for now is either --disable-gl to disable using the glx module or --disable-macosx to disable all of the macosx- foo... if you choose --disable-macosx, you'll run into problems... I just pushed some changes to macports svn to address that. --Jeremy On Apr 22, 2009, at 21:07, Jeremy Huddleston wrote:
So... I looked at the mplayer source...
The mplayer build system is fubar, and I don't want to try fixing it. They're using a common set of ldflags for everything indiscriminately.
gl_common.c is for GLX and is used for vo_gl and vo_gl2. vo_macosx.m is for vo_macosx. The former needs -lGL with no -fw OpenGL, the latter needs -fw OpenGL with no -lGL.
Feel free to send this info upstream and give me a bug number to follow, but their build system is not clean enough for me to want to try patching.
On Apr 22, 2009, at 20:59, Jeremy Huddleston wrote:
Then the problem is much deeper in that it's trying to mix GLX and CGL at the same time. My guess is that this is a complicated and incorrect set of #ifdefs... many applications have such problems, and I've been working with upstream developers to get them fixed as I've run into them.
mplayer should have two output plugins for gl. One is macosx which should be linked with '-fw OpenGL'; the other is glx which should be linked with -lGL.
The fact that glXDestroyContext is referenced from a file called gl_common.c scares me because it seems that their "common GL" code actually isn't GL at all but GLX. This is definitely an mplayer bug, so please file this issue upstream, and let me know the URL to the bug, so I can follow up with those developers.
On Apr 22, 2009, at 20:49, vmrsss wrote:
PS. If I remove -lGL, linking fails because of
Undefined symbols: "_glXChooseVisual", referenced from: _config in vo_gl.o "_glXCreateContext", referenced from: _setGlWindow in gl_common.o "_glXGetConfig", referenced from: _initGl in vo_gl2.o _initGl in vo_gl2.o _initGl in vo_gl2.o _initGl in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o _config in vo_gl2.o "_glXSwapBuffers", referenced from: _swapGlBuffers in gl_common.o "_glXDestroyContext", referenced from: _releaseGlContext in gl_common.o _setGlWindow in gl_common.o _setGlWindow in gl_common.o "_glXMakeCurrent", referenced from: _releaseGlContext in gl_common.o _setGlWindow in gl_common.o
which are not in /System/Library/Frameworks/OpenGL.framework/ Libraries/libGL.dylib nor in OpenGL, apparently. (Sorry for being so ignorant about all this...) _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
participants (3)
-
Jeremy Huddleston
-
Jeremy Huddleston
-
vmrsss