32-bit GLX (nvidia) not working after update, unless running with strace
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I just thought about the fact that it is a difference in ld-2.39.so which is causing the problem, so there should be a way to check the differences and find out what changed?
I did objdump and diff them, but then realised I have no idea what I'm doing
I have uploaded the bad- and the good- ld-2.39.so here in case anyone wants to try figuring out the difference: http://135.125.183.217/glibc/
The crash occurs in _dl_open
So, after comparing the two ld-2.39.so's I saw they are almost identical and the only change is instructions like "lea 0x0(%esi,%eiz,1),%esi" got changed to "lea %cs:0x0(%esi,%eiz,1),%esi" when glibc was built with binutils-2.42. No idea what it does, but that %cs is added to the start of the register? on all of them.
So I searched and found https://inbox.sourceware.org/binutil...c1bd@suse.com/
If I reverse this patch from binutils-2.42, recompile binutils, then recompile glibc.. then it works with 32 bit glx. So this patch seems to cause the problem.
The strange thing is I tried downloading the Arch version of lib32 ld-2.39 and compare it to the Slackware one and they look very different. The Arch one doesn't even have a _dl_open mentioned in it. It does have the "%cs:0x0(%esi,%eiz,1),%esi" lines a few times though.
edit: but really all we can do is wait for nvidia to compile the driver using binutils-2.42 and see if it works then.
edit: but really all we can do is wait for nvidia to compile the driver using binutils-2.42 and see if it works then.
I'm a bit surprised this hasn't happened to other distros yet, if it's an issue with binutils. They weren't back-patching glibc for the CVE, were they?
It obviously doesn't affect enough people that they would do anything special about it, and I guess they will be updating their build tools at some point so it will just "fix itself".
I do find it strange that not more Slackware users have mentioned a problem though, are there really only 4 Slackware users who use Nvidia and steam?
edit: I forgot it's a Slackware-current problem, 15 is still on binutils 2.37.
It obviously doesn't affect enough people that they would do anything special about it, and I guess they will be updating their build tools at some point so it will just "fix itself".
I do find it strange that not more Slackware users have mentioned a problem though, are there really only 4 Slackware users who use Nvidia and steam?
edit: I forgot it's a Slackware-current problem, 15 is still on binutils 2.37.
Make it five, at least ;-) Thank you to everyone in thread who's spent time beating on this problem!
Since the workaround of running under debugger was posted before I ran into this problem, have just been checking in for updates every so often.
It obviously doesn't affect enough people that they would do anything special about it, and I guess they will be updating their build tools at some point so it will just "fix itself".
I do find it strange that not more Slackware users have mentioned a problem though, are there really only 4 Slackware users who use Nvidia and steam?
edit: I forgot it's a Slackware-current problem, 15 is still on binutils 2.37.
I was talking the nvidia people, not the Slackware people! Then again big corporation, not a lot of people with the bug, etc.
I was talking the nvidia people, not the Slackware people! Then again big corporation, not a lot of people with the bug, etc.
Yes, I meant nvidia too
They might have noticed that we have the problem but it's not affecting stable Slackware or any other distro (yet?) so nvidia won't worry about it and might just wait to see if it gets fixed in their next build of libGLX_nvidia
I wouldn't expect a changelog from a big company to give all the details nowadays
I did just reinstall alienbobs multilib and tested /usr/bin/32/glxinfo with the OLD nvidia and it still crashed.
I then copied the libGLX_nvidia.so.550.54.14 from the new nvidia driver (and ran ldconfig) and now 32bit glxinfo works.
So it looks like they did fix it, or it got fixed by magic when it was recompiled with new binutils
I didn't actually install the full nvidia driver, I only copied the libGLX from it but all the other libs and kernel modules are the old nvidia. So I will update it properly now and see if it still works.
Huh. I did install the new driver, and it still crashed for me. (With the added "benefit" of the framebuffer bug, even booting with the new parameters suggested...)
Huh. I did install the new driver, and it still crashed for me. (With the added "benefit" of the framebuffer bug, even booting with the new parameters suggested...)
Yes, it is broken for me too now I fully installed the new nvidia driver. So, that's weird
It seems that using a mismatched version of libGLX_nvidia to the rest of the nvidia libs also "fixes" it, but also makes things even more confusing.
I now have 550.54.14 installed system wide, but copied libGLX_nvidia.so.535.154.05 from the old version and updated the libGLX_nvidia.so.0 symlink, and now 32 bit glx is working again.
But, just replacing the libGLX with a different version doesn't work. You need to have both versions there, but the symlink pointing to the _wrong_ version for your system. Then 32-bit glx is happy.
This is how it looks on my system now with 550.54.14 installed
Code:
/usr/lib# ls -l libGLX_nvidia.so.*
lrwxrwxrwx 1 root root 27 Feb 23 18:23 libGLX_nvidia.so.0 -> libGLX_nvidia.so.535.154.05*
-rwxr-xr-x 1 root root 1218244 Feb 23 18:23 libGLX_nvidia.so.535.154.05*
-rwxr-xr-x 1 root root 1230564 Feb 23 18:23 libGLX_nvidia.so.550.54.14*
I got the error "couldn't find RGB GLX visual or fbconfig" when I overwrote libGLX_nvidia.so.550.54.14 with libGLX_nvidia.so.535.154.05, so it looks like it first tries the wrong lib and fails, but then successfully loads the correct lib without segfaulting.
Yes, it is broken for me too now I fully installed the new nvidia driver. So, that's weird
It seems that using a mismatched version of libGLX_nvidia to the rest of the nvidia libs also "fixes" it, but also makes things even more confusing.
That sounds like a them problem... I think I'm staying on the 535 driver that works for me (that is, will resume console after exiting X) and using strace a bit longer. Logically, it shouldn't work with mismatched libraries, unless it's the same fudge that makes strace work.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.