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.

1 members found this post helpful.

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?

Hrm. crickets on the nvidia forum thread. A "hey thanks for doing our work for us" would've been nice after all the bisecting you did...

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.

1 members found this post helpful.

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.

1 members found this post helpful.

I also have same problem, but since I am not that smart as you guys, I am just listening

Thanks for all the investigations so far!

1 members found this post helpful.

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

1 members found this post helpful.

Same problem as well, thank you guys for your helpful posts, I'm keeping an eye on this thread, thank you all again!

https://www.gamingonlinux.com/2024/0...sed-as-stable/ Hrm. no mention of 32-bit OpenGL libraries.

1 members found this post helpful.

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...)

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
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.

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.