Bugzilla – Bug 988273
Steam segmentation fault in libcrypto
Last modified: 2018-03-14 07:30:33 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Steam crashes immediately after starting due this bug https://github.com/ValveSoftware/steam-for-linux/issues/4504
Steps to Reproduce:
1. Install steam 126.96.36.199
2. Run it
Steam crashes with segmentation fault.
Steam works fine.
There is fix/workaround for this http://www.gearsongallium.com/?p=3276#utm_source=feedly&utm_medium=rss&utm_campaign=fix-for-segmentation-fault-in-libcrypto-steam-beta mesa must be compiled with libnettle:
From looking at the discussion on Github, I don't understand why building Mesa with libnettle would help when steam running with the system provided libcryto - ie without the steam provided runtime librypto - doesn't work.
This seems to be a libcrypto issue: Before we do any changes in the built of Mesa, the libcrypto & steam maintainers should have a look at this.
Reassigning to the maintainer of openssl.
@Egbert, SR#407423 for TW and SR#407424 for Leap:42.1 is workaround with libnettle + update to 12.0.1 / 11.0.9
comment by Marek Olsak is clear : BTW, this is libcrypto developers' fault, because they had changed their public interface, which is the cause of this incompatibility.
and because steam isn't in our control ..
This is an autogenerated message for OBS integration:
This bug (988273) was mentioned in
https://build.opensuse.org/request/show/407424 42.1 / Mesa
(In reply to Ondřej Súkup from comment #2)
> @Egbert, SR#407423 for TW and SR#407424 for Leap:42.1 is workaround with
> libnettle + update to 12.0.1 / 11.0.9
> comment by Marek Olsak is clear : BTW, this is libcrypto developers' fault,
> because they had changed their public interface, which is the cause of this
When the run time libs shipped by steam are not used /lib/libcrypto.so.1.0.0 is used by both Mesa and steam. Where do you see an ABI breakage?
I would like the maintainer of openssl (where libcryto comes from) to look into this issue before we change anything in Mesa.
> and because steam isn't in our control ..
Of course not. But is this a valid reason to do kludge around this by adapting other packages?
I've declined the SRs for Mesa for now due to the change of crypto libs for now.
I'd like to understand the issue better.
I'm fine with the other updates.
(In reply to Egbert Eich from comment #4)
> (In reply to Ondřej Súkup from comment #2)
> > @Egbert, SR#407423 for TW and SR#407424 for Leap:42.1 is workaround with
> > libnettle + update to 12.0.1 / 11.0.9
> > comment by Marek Olsak is clear : BTW, this is libcrypto developers' fault,
> > because they had changed their public interface, which is the cause of this
> > incompatibility.
> WHich incompatibility?
> When the run time libs shipped by steam are not used
> /lib/libcrypto.so.1.0.0 is used by both Mesa and steam. Where do you see an
> ABI breakage?
i think steam binary uses steamclient.so and steamservice.so with integrated libcrypto into this two libraries ... and here might be incompactibility between steam and Mesa used libs
> I would like the maintainer of openssl (where libcryto comes from) to look
> into this issue before we change anything in Mesa.
> > and because steam isn't in our control ..
> Of course not. But is this a valid reason to do kludge around this by
> adapting other packages?
> I've declined the SRs for Mesa for now due to the change of crypto libs for
> I'd like to understand the issue better.
> I'm fine with the other updates.
(In reply to Ondřej Súkup from comment #5)
> i think steam binary uses steamclient.so and steamservice.so with integrated
> libcrypto into this two libraries ... and here might be incompactibility
> between steam and Mesa used libs
What do you mean? Statically linked? I very much doubt this.
It could well be that we are seeing different versions of the same lib loaded and functions from different versions being called for the same sha1 calculation.
What I still don't understand is that this also happens when nut using the steam provided runtime.
Unless the openssl maintainer is aware of any issue with a recent version of libcrypto, this needs to be investigated more thoroughly - by the steam package maintainers: presently, I don't have the time for this.
(In reply to Egbert Eich from comment #6)
> What do you mean? Statically linked? I very much doubt this.
They statically link openssl in ~/.local/share/Steam/ubuntu12_32/steamclient.so
Not seeing an action for maintenance just now (request review declined by maintainer). Removing needinfo flag.
Almost two weeks have passed and still there is no progress. Steam doesn't work all that time, though the solution was provided. What can I do to speedup issue resolving?
Does replacing libcrypto with libnettle using the patched Mesa package from https://build.opensuse.org/package/show/home:boombatower:tumbleweed++/Mesa resolve it for you?
It does, but I think this fix should be presented in default repo.
(In reply to Dmitry Misharov from comment #11)
> It does, but I think this fix should be presented in default repo.
The claimed 'solution' wasn't a solution but a workaround. It was not even clear why the workaround actually worked as this was never investigated.
In comment #5 and #7 it is claimed that steam statically links against libcrypto. The explanation given in the link provided in comment #7 explains the situation around statically linked libs and provides a workaround which doesn't require to touch other components of the system.
Yet, the backtraces shown in the links provided in the original bug description contradict this static linking.
Again, we cannot fix this issue in Mesa - we will not touch system components to work around issues with proprietary 3rd party applications. It is just wrong and *will* *not* *happen*.
Some other workaround needs to be found which will remain local to steam. Someone just needs to investigate this thoroughly and come up with a full explanation and sensible workaround. I don't have the time for this presently - sorry.
I agree in principle that workarounds should be kept localized, but is there a reason why compiling Mesa with libnettle is a bad thing? The ABI breakage in libcrypto might cause other closed source applications to crash.
(In reply to Matthias Mailänder from comment #13)
> I agree in principle that workarounds should be kept localized, but is there
> a reason why compiling Mesa with libnettle is a bad thing? The ABI breakage
> in libcrypto might cause other closed source applications to crash.
because it overrides fixes for openSSL and creates bigger problem with maintenance.. + bug is on Steam/Valve side
the backtrace shows it embdes a copy of libcrypto.so.1.0.0 ...
canb this be removed perhaps and the system one used, perhaps this helps already
find ~/.local/share/Steam/ubuntu12_32/steam-runtime -type f -name "libcrypto*" -print -delete
find ~/.local/share/Steam/ubuntu12_32/steam-runtime -type f -name "libgpg*" -print -delete
as suggested in https://bugs.archlinux.org/task/48994 did help on my TW system.
*** Bug 996928 has been marked as a duplicate of this bug. ***
I've marked my bug as a duplicate of this since it's the same, segmentation fault at line 713. This affects both TW and Leap 42.2 beta. Many people suffer from this, and Steam is still the main software for those who play on linux, not having a fix for this is a shame for all who use Opensuse. I've contacted Valve, and on their side, their response is to use ubuntu 12.04 or any other Buntu OS. So a fix needs to come from the community...
It should definitely be added to the 42.2 Release Notes so people who want to use Steam for gaming know that they can't upgrade yet.
On Reddit it was suggested that we look into the command line version as a temporary alternative and for server admins. I started experimenting with it at https://build.opensuse.org/package/show/home:Mailaender:branches:games:tools/steamcmd
I'm not 100% sure on how the conflict causes the seg fault with static vs dynamic so excuse any ignorance.
openssl 1.1.0 is out now. Has anyone had the chance to check it is still an issue? What specifically changed with libcrypto to break it, I couldn't see anything in the changelog?
Why is libnettle such a bad idea? It's already in the official repos and the only use of libnettle in mesa is for SHA1 which is AFAIK only used by shader code. Not exactly security centric and I couldn't find any openssl specific patches on mesa's obs.
There's about 4 compiles of mesa with libnettle in obs and I've been using boomba's for several months now without any adverse affects.
- tumbleweed ... i fixed up the cpuid call when using the system libraries, but then it also crashes in RSA_free -> ENGINE_finish with a corrupted pointer
I debugged this more.
The secondary crash (besides the cpuid one).
The binary "steam" has a static libcrypto.a built in. RSA_new() is called in it.
This initializes all of the RSA struct, except the "engine" pointer, because engines are not built in the static build.
While RSA_new is called in this static build, RSA_free is called in the shared library, which has engine support. There it tries to dereference RSA->engine if it is not NULL and that crashes.
I went an opened a steam issue.
I also went and opened pull requests for openssl to initialize RSA->engine to NULL, for 1.0.1 and 1.0.2 branch, so if that is accepted and published and steam picks it up, it will in their static builds too.
The latest snapshot has fixed the issue. Thanks to everyone who helped with the resolving. You are awesome.
Indeed, great work! To solve this once and for all we may need to build every library from the Steam runtime from source https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=steam-libs as relying on the Ubuntu 12.04 ones is a fundamentally broken concept from Valve. I added a warning to Tumbleweed users to https://en.opensuse.org/Steam for now.
https://www.reddit.com/r/openSUSE/comments/5867hg/steam_cs_go_working_again_in_tumbleweed/d8ycve8 Some compliments for the hero of the openSUSE gaming community. :)
For me this seems to be still broken on openSUSE 42.2.
Anyone else tested this on 42.2?
So either please:
- please reopen this bug until it's fixed for 42.2
- bug 996928 isn't a duplicate, because it was specifically for 42.2
Steam works on openSUSE 42.2. So for now the status of this issue should be stay as is.
Take a look at https://bugzilla.opensuse.org/show_bug.cgi?id=1017891, I wasn't able to fix steam for Star Conflict or Strife. This bug is still present in 42.2.
Steam works for Valve: Robocraft, Team Fortress and probably others, for War Thunder. This bug is not fixed yet. Please investigate!
(In reply to kolA flash from comment #28)
> For me this seems to be still broken on openSUSE 42.2.
> Anyone else tested this on 42.2?
> So either please:
> - please reopen this bug until it's fixed for 42.2
> - bug 996928 isn't a duplicate, because it was specifically for 42.2
Sorry for my previous comment.
I didn't installed Steam from the openSUSE-42.2-NonOSS repo, so my Steam didn't used the Steam fixing stuff.
(line 43 - 60)
I manually linked those libraries into a non-YaST Steam installation and now that Steam is working fine on 42.2!
This is an autogenerated message for OBS integration:
This bug (988273) was mentioned in
https://build.opensuse.org/request/show/586663 15.0:NonFree / steam