Rust Install Causes Segmentation Fault

help
1

I'm not sure if this is an OS issue or a Rust issue, but I'm having trouble getting Rust installed. I just get a Segmentation Fault.

My first install attempt was using the command from the website:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

It seems to have run fine, but rustc fails:

rustc -vV
Segmentation fault (core dumped)

It doesn't matter what options I try with rustc, but it fails.

rustc --version
fish: Job 1, 'rustc --version' terminated by signal SIGSEGV (Address boundary error)

rustup seems to work fine:

rustup --version
rustup 1.28.2 (e4f3ad6f8 2025-04-28)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `(error reading rustc version)`

I also tried installing with rustup. I tried both the stable and the nightly.

I'm running on Garuda linux, so I tried using octopi to install the rust package and then the rustup package.

I thought I saw somewhere that starfish might be interfering so I tried to run it in a new bash terminal with the same results.

I just tried checking my path. It looks correct, and both versions fail. Then, I noticed that both are linked to rustup. Is it supposed to be like that?

>which rustc
/home/skp/.cargo/bin/rustc

>rustc -vV
fish: Job 1, 'rustc -vV' terminated by signal SIGSEGV (Address boundary error)

>/usr/bin/rustc -vV
fish: Job 1, '/usr/bin/rustc -vV' terminated by signal SIGSEGV (Address boundary error)

>ls -l /usr/bin/rustc
lrwxrwxrwx - root  2 Jun 04:45  /usr/bin/rustc -> /usr/bin/rustup

>ls -l /home/skp/.cargo/bin/rustc
lrwxrwxrwx - skp 15 Jun 22:24  /home/skp/.cargo/bin/rustc -> rustup

Almost all the search results for this error turns up people struggling with their programs causing memory errors. Since I can't even get a version number from rustc, I'm way before that point. I have a feeling it's a dependency that I'm missing, but I'm not sure where to go from here. Should I take this to a Garuda Linux forum, or is this an issue with rustc? Or, am I just missing something obvious.

2

Poking around on a few other threads, I found one talking about strace working. It doesn't work for me, but it does give some more details:

mprotect(0x7fecdb862000, 4096, PROT_READ) = 0
mprotect(0x7fecdc07e000, 69632, PROT_READ) = 0
mprotect(0x7fecdbbec000, 77824, PROT_READ) = 0
mprotect(0x7fece83e1000, 4096, PROT_READ) = 0
mprotect(0x7fece59fb000, 16384, PROT_READ) = 0
mprotect(0x7fececa1a000, 4096, PROT_READ) = 0
mprotect(0x7fece8517000, 32768, PROT_READ) = 0
mprotect(0x7fece8555000, 8192, PROT_READ) = 0
mprotect(0x7fece857e000, 4096, PROT_READ) = 0
mprotect(0x7fececa27000, 4096, PROT_READ) = 0
mprotect(0x7feceedf5000, 4096, PROT_READ) = 0
mprotect(0x7fececa43000, 4096, PROT_READ) = 0
mprotect(0x7feceed00000, 4096, PROT_READ) = 0
mprotect(0x7fececa4c000, 4096, PROT_READ) = 0
mprotect(0x7feceed10000, 4096, PROT_READ) = 0
mprotect(0x7fececbac000, 339968, PROT_READ) = 0
mprotect(0x7fece5597000, 2023424, PROT_READ) = 0
mprotect(0x7fecef155000, 4096, PROT_READ) = 0
mprotect(0x7feceedfe000, 4096, PROT_READ) = 0
mprotect(0x7fecef167000, 4096, PROT_READ) = 0
mprotect(0x7fece80f5000, 806912, PROT_READ) = 0
mprotect(0x7fecef1ab000, 57344, PROT_READ) = 0
futex(0x7fecdc0906bc, FUTEX_WAKE_PRIVATE, 2147483647) = 0
lseek(2, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
fstat(2, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0), ...}) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7fecf75a2ec0} ---
+++ killed by SIGSEGV (core dumped) +++
fish: Job 1, 'strace -f rustc --version' terminated by signal SIGSEGV (Address boundary error)

I did also learn that the linking is normal. It is actually running:
~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc --version

That gives me the same segmentation fault though.

3

I highly suspect it's either the OS had some unusual modification to the kernel, or some of the system libraries like glibc, libgcc, etc., since the toolchain installed by rustup had bundled its own copy of llvm, there are very few external libraries that are dependencies on the local operating system, such as libc, libgcc, libpthread.

yes, rustup works as proxies to the real program, in order to support different toolchain versions. see:

first of all, make sure the correct toolchain was installed, e.g. -musl vs -gnu

$ rustup toolchain list

then, to see if there's dependency missing, try:

$ ldd $(rustup which rustc)

also, you can examine the core dump to see if you can get a stack trace, which will help locate the crash.

4

Thanks for the reply...

$ rustup toolchain list
stable-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (active, default)

And for the dependencies one:

$ ldd $(rustup which rustc)
linux-vdso.so.1 (0x00007fd92cd7d000)
/usr/NX/lib/libnxegl.so (0x00007fd92c600000)
librustc_driver-01acad332a4cdc9a.so => /home/skp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-01acad332a4cdc9a.so (0x00007fd924a00000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fd92cd35000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007fd92cd30000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fd92cd2b000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fd924810000)
libLLVM.so.20.1-rust-1.89.0-nightly => /home/skp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.20.1-rust-1.89.0-nightly (0x00007fd91ac00000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fd92ccfc000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fd92c908000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd92cd7f000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007fd92cce3000)

I'll do a little more reading, too. Thanks for the link.

5

Ok, so I just discovered the coredmpctl program:

coredumpctl gdb -1
PID: 304045 (rustc)
UID: 1000 (skp)
GID: 1000 (skp)
Signal: 11 (SEGV)
Timestamp: Tue 2025-06-17 22:26:01 EDT (1min 31s ago)
Command Line: /home/skp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc --version
Executable: /home/skp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole@c9d366b4320545f7a24f25eb7e1686ad.service
Unit: user@1000.service
User Unit: app-org.kde.konsole@c9d366b4320545f7a24f25eb7e1686ad.service
Slice: user-1000.slice
Owner UID: 1000 (skp)
Boot ID: e71a374e7b224d8a8d3cfae664dbd7b1
Machine ID: 0f3a04dc2b2c4f0db607cad1b7aad8a6
Hostname: pine-nut
Storage: /var/lib/systemd/coredump/core.rustc.1000.e71a374e7b224d8a8d3cfae664dbd7b1.304045.1750213561000000.zst (present)
Size on Disk: 3.2M
Message: Process 304045 (rustc) of user 1000 dumped core.

Module /home/skp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc without build-id.
Module libLLVM.so.20.1-rust-1.89.0-nightly without build-id.
Module librustc_driver-01acad332a4cdc9a.so without build-id.
Module libnxegl.so without build-id.
Stack trace of thread 304045:
#0  0x00007ff660292c17 n/a (libLLVM.so.20.1 + 0x692c17)
#1  0x00007ff6852c92f7 n/a (ld-linux-x86-64.so.2 + 0x52f7)
#2  0x00007ff6852c93cd n/a (ld-linux-x86-64.so.2 + 0x53cd)
#3  0x00007ff6852c64b5 _dl_catch_exception (ld-linux-x86-64.so.2 + 0x24b5)
#4  0x00007ff6852d00c9 n/a (ld-linux-x86-64.so.2 + 0xc0c9)
#5  0x00007ff6852c6416 _dl_catch_exception (ld-linux-x86-64.so.2 + 0x2416)
#6  0x00007ff6852d04de n/a (ld-linux-x86-64.so.2 + 0xc4de)
#7  0x00007ff67d2a1b34 n/a (libc.so.6 + 0x91b34)
#8  0x00007ff6852c6416 _dl_catch_exception (ld-linux-x86-64.so.2 + 0x2416)
#9  0x00007ff6852c6569 n/a (ld-linux-x86-64.so.2 + 0x2569)
#10 0x00007ff67d2a1623 n/a (libc.so.6 + 0x91623)
#11 0x00007ff67d2a1beb dlopen (libc.so.6 + 0x91beb)
#12 0x00007ff672c1388d n/a (libEGL.so.1 + 0xa88d)
#13 0x00007ff672c1412c n/a (libEGL.so.1 + 0xb12c)
#14 0x00007ff67d2aacb4 n/a (libc.so.6 + 0x9acb4)
#15 0x00007ff67d2aad29 pthread_once (libc.so.6 + 0x9ad29)
#16 0x00007ff672c124e8 eglGetProcAddress (libEGL.so.1 + 0x94e8)
#17 0x00007ff68500f1d6 nxeglFunctionsInit (libnxegl.so + 0xf1d6)
#18 0x00007ff685005a28 n/a (libnxegl.so + 0x5a28)
#19 0x00007ff6852c92f7 n/a (ld-linux-x86-64.so.2 + 0x52f7)
#20 0x00007ff6852c93cd n/a (ld-linux-x86-64.so.2 + 0x53cd)
#21 0x00007ff6852e1620 n/a (ld-linux-x86-64.so.2 + 0x1d620)
ELF object binary architecture: AMD x86-64

GNU gdb (GDB) 16.3
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/skp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc...
(No debugging symbols found in /home/skp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc)
[New LWP 304045]

This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) n
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/home/skp/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc --version'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007ff660292c17 in ?? () from /usr/lib/libLLVM.so.20.1
Function(s) ^std::(move|forward|as_const|(__)?addressof) will be skipped when stepping.
Function(s) ^std::(shared|unique)_ptr<.*>::(get|operator) will be skipped when stepping.
Function(s) ^std::(basic_string|vector|array|deque|(forward_)?list|(unordered_|flat_)?(multi)?(map|set)|span)<.*>::(c?r?(begin|end)|front|back|data|size|empty) will be skipped when stepping.
Function(s) ^std::(basic_string|vector|array|deque|span)<.*>::operator.] will be skipped when stepping.
(gdb)
6

I don't think this is the full strace output, right? it should start with an execve call. but anyways, to me, it looks like a crash somewhere inside the dynamic linker, as indicated by the consecutive mprotect syscalls.

this library is not present on my system, so I assume it's specific to your distribution. I don't know about it, but guessing from the name, it's probably related to some egl driver. apparently, the OS distribution is doing some form of aggressive modification (optimization?) to the low level libraries. I'm not supprised if some of the mods made the dynamic linker unstable.

7

No, sorry. It was just the tail of the strace. I was afraid it would make the post too long to scroll through. I just tried to include the whole thing in a "details" section, but it claimed the post was too many characters. Is there a better way to attach the full thing?

I'll do some more research on the libnxegl library.

Another clue I noticed is that I have flutter installed and have been using it with no problems. After trying to install this, the flutter program stopped compiling. It makes me wonder if Garuda has a special version of rust that they've made compatible.

8

Searching on that library brought me to this post:

Uninstalling the nomachine package, seems to have made a difference. Now, I get this:

$ rustc --version
ERROR: ld.so: object '/usr/NX/lib/libnxegl.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/NX/lib/libnxegl.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/NX/lib/libnxegl.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/NX/lib/libnxegl.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
rustc 1.89.0-nightly (f3db63916 2025-06-17)
ERROR: ld.so: object '/usr/NX/lib/libnxegl.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/NX/lib/libnxegl.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

I'm going to reboot and see what happens.

9

so it is the libnxegl.so that is causing the problem, and it can also seen from the stack trace of the core dump.

apparently, this library was using LD_PRELOAD to inject itself to every proces, IMO this is kind of scary.

now that the package is uninstalled, you just need to remove it from LD_PRELOAD to silent these warnings.

if you configured it manually, just remove it from your ~/.bash_profile or equivalence file for your shell. if the package were installing a system-wide configuration without user consensus, than I would be very upset about the packager.

10

The reboot didn't fix it.

ldconfig -p gives me errors

I ended up reinstalling it, and then running this command:

sudo /usr/NX/scripts/setup/nxserver --uninstall

That still didn't work!

So, I found this post:

Running this, I found the one file that was missed:

$ls /etc/udev/rules.d/99-virtualgl-dri.rules /etc/opt/VirtualGL /usr/share/sddm/scripts/Xsetup /usr/share/gdm/greeter/autostart/virtualgl.desktop /etc/modprobe.d/virtualgl.conf /etc/X11/xorg.conf.d/99-virtualgl-dri
.rwxr-xr-x 66 root 17 Jun 23:17  /usr/share/sddm/scripts/Xsetup

This ended out being the final fix
https://kb.nomachine.com/TR02W11273#:~:text=Status:%20Open-,The%20LD_PRELOAD%20variable%20is%20set%20in%20the%20environment%20of%20all,logging%20out%20from%20the%20system.

sudo rm  /etc/xdg/plasma-workspace/env/nx-sourceenv.sh

Now it works!

$ rustc --version
rustc 1.87.0 (17067e9ac 2025-05-09)

And, my Hello, World works too!

$ rustc main.rs
$ ./main
Hello, world

Thanks so much!