The crash here appears to be from an incompatibility between libUnrealEditor-DerivedDataCache.so (statically links and globally exports 877 OpenSSL 1.1.1t symbols -- confirmed via nm -D and embedded version string) and the system NVIDIA driver (libcuda.so.1 / libnvidia-glcore.so). The NVIDIA driver loads the system libcrypto.so.3 and calls RAND_bytes_ex (an OpenSSL 3.x-only function). During RAND subsystem initialization, pthread_once resolves CRYPTO_THREAD_run_once to UE’s OpenSSL 1.1.1t implementation rather than OpenSSL 3.x’s. The ABI mismatch between the two versions’ internal locking and hash table structures causes the segfault in OPENSSL_LH_retrieve.
Open questions:
Is there a supported configuration for UE 5.4.4 / 5.7.4 Linux + NVIDIA 570.x + system OpenSSL 3.x?
Is there a planned fix to hide the statically-linked OpenSSL symbols from global scope?
Are there other recommended workarounds that preserve Vulkan rendering (e.g., environment variables, engine .ini settings)?
We are planning to upgrade OpenSSL because 1.x is EOL, but haven’t completed it yet. I’ve reached out internally to see if there are known workarounds.
And we’re back! It sounds like the main difference here between your use case and what we test is Debian13. It looks like Debian ships a newer version of OpenSSL than Ubuntu, but it’s still 3.x so we should be hitting this too. We primarily use Ubuntu, do our testing on it and it’s what we recommend. It’s possible we didn’t test on the exact driver but we have developers using the 570 drivers on Ubuntu that have OpenSSL 3.x and don’t have this issue - however they’re likely running with a source build.
Can you run this to provide more info about the libraries being used?
LD_DEBUG=bindings,symbols ./UnrealEditor 2>&1 | grep -iE 'CRYPTO_THREAD_run_once|OPENSSL_LH_retrieve' And this
cd /lib/x86_64-linux-gnu # or wherever the 570 driver lives
for l in libcuda.so.1 libnvidia-glcore.so* libnvidia-eglcore.so* libGLX_nvidia.so.0 \
libnvidia-gpucomp.so* libnvidia-rtcore.so* libnvidia-ngx.so.1; do
echo "== $l"
nm -D "$l" 2>/dev/null | grep -E '^ *U ' | grep -iE 'RAND_bytes|CRYPTO_|OPENSSL_|EVP_'
objdump -p "$l" 2>/dev/null | awk '/NEEDED/&&/(ssl|crypto)/{print " NEEDED",$2}'
done
In our minimal testing so far (580.95.05, 570.124.06) the libnvidia-glcore.so libs have no undefined symbols, and some libcuda.so.1 have no OpenSSL symbols at all - but this is mainly on Ubuntu.
Unfortunately the file failed to upload correctly, can you try uploading it as a zip? If it fails again sometimes it helps to just put an arbitrary image in the post that has the attachment.
We’ve looked the the output and out3.txt seems to confirm your 570 driver doesn’t have any openssl or crypto symbols which matches what we see on Ubuntu 22.04. out1.txt also matches what we see and shows the symbol collision but the two commands themselves don’t show why that would trigger any issue unless you’re building some other library that uses libcrypto?
Do you have custom code, or plugins that you’re using or is this a vanilla UE project? It almost sounds like there’s a plugin that got built against the system libs instead of the UE toolchain and sysroot.
Are you overriding LD_LIBRARY_PATH, LD_PRELOAD, LD_LIBRARY_PATH, LD_BIND_NOW, OPENSSL_CONF or OPENSSL_MODULES?
Aside from the info about, it would be helpful to have a full log and maybe a core dump.
Thanks for providing the crash info. This does make it look like your setup is different in that it requires a per-GPU license, so likely the driver is talking to the license server. Can you try running the following command to see if it returns Expiry N/A or something else:
nvidia-smi -q | grep LicWe are not likely going to be able to reproduce this with our passthrough drivers, but are attempting to prototype a way of importing/exporting UE symbols to avoid collisions.
Thanks for testing the fix! We’ve already submitted the change to UE6:
CL#55974958 (0ffae9) Linux: isolate bundled OpenSSL symbols via a private version script
- Fixes a crash on system with cloud licensing where the gfx drivers load SSL libraries themselves.
We are working to get it merged into a 5.8.x release. We have no plans to make any additional releases for engine versions older than 5.8 but will post a public technote with the patch to integrate on the Epic Developer Community which can be applied to older engine versions. User’s affected by this issue will need to build the engine from source with the patch.
Please let me know if you have any additional questions, otherwise I’ll go ahead and close this ticket.
Sure thing. I’ve attached the outputs in sequence.
I’ve been pretty perplexed at why this is an issue, too; none of our testing machines have an issue (and they all run Debian 13), and “NVIDIA + OpenSSL” seems like a common enough configuration amongst linux users who would have installed Unreal that I’m surprised this hasn’t shown up before (goes back at least as far as v5.4.4).
The biggest difference I can discern between my machine (failing) and our testing infrastructure (working) is that my machine is a VDI with a high-performance L40 GPU that requires a licensed driver. The license stuff seems like an explanation for why libcuda is reaching out for OpenSSL functions, and this is a far more unique environment amongst Unreal users which could explain the lack of issue before.
Very interesting. I’m not aware of any other hard dependencies on libcrypto. If the 570 driver doesn’t have any symbols for that, why would it be causing issues?
> Do you have custom code, or plugins that you’re using or is this a vanilla UE project?
I originally observed this in a custom project with our own C++ plugin (but no dependencies on libcrypto or anything adjacent). I can reproduce it fully with both the prebuilt versions of Unreal 5.4.4 and 5.7.4 from https://www.unrealengine.com/linux with no customizations. Just download and unpack the archive and run ./Engine/Binaries/Linux/UnrealEditor => crash. No overrides of LD_* or OPENSSL_* environment variables that I can see (unless something sets them in starting the editor).
I’ve attached logs from a few recent sessions with a crash, both from custom project and just opening the editor (as above). I’ve also sent off a few reports from the automated crash reporter tool, if those are accessible
That the driver is doing some secure/crypto licensing thing is undoubtedly the environmental piece that makes this happen on my machine (and my machine alone). I’m pretty sure I’m the only one in our office who has access to a linux system in VDI with a high-powered L40 GPU. Our system support team confirmed those GPUs require regular license checkouts.
From what I’ve been able to determine, libUnrealEditor-DerivedDataCache.so, libUnrealEditor-SSL.so, libUnrealEditor-DevHttp.so, libUnrealEditor-Zen.so, and libUbaHost.so) each have OpenSSL 1.1.1t statically linked and also publish things to the global dynamic symbol table. When the vGPU driver loads the system’s libcrypto.so.3 (OpenSSL 3.5.6) during Vulkan device creation, the dynamic linker resolves OpenSSL 3.x’s internal function calls to (the re-published and incompatible) 1.1.1 implementations because UE’s symbols were loaded first and have higher priority in the global table. (Basically, ELF-coded libraries expose symbols by default and only privatize them if explicitly instructed.)
I think I have a modification to the editor source that scopes that down and prevents the re-export of all of those symbols. As a diff,
This allows me to rebuild and launch the editor successfully. It’s a workaround for me now, but this doesn’t solve the full issue since we can’t rely on custom editor development and use precompiled Edtior/Engine binaries from https://www.unrealengine.com/linux
Unlucky news: that diff doesn’t fully work. It gets me over the first crash (when I try to *open* the editor), but that just moves the issue to a second crash (when I try to start a PIE session).
