Cannot allocate memory in static TLS block

Hey, all. I'm working on a linter based on dylint and I'm getting this error while trying to run dylint:

Failed to load library $TARGET/release/lib$NAME@nightly-2025-08-07-x86_64-unknown-linux-gnu.so: $HOME/.rustup/toolchains/nightly-2025-08-07-x86_64-unknown-linux-gnu/lib/librustc_driver-12dbd1970610030b.so: cannot allocate memory in static TLS block

Running readelf -Wl .../librustc_driver-12dbd1970610030b.so shows that this SO by itself is trying to allocate 8.6 KiB of TLS, which if my understanding that the limit on Linux is 2 KiB, would be simply wrong. Am I missing something or is this build of rustc_driver simply broken? Is there any way I can work around this?

Thanks.

For performance reasons librustc_driver.so is compiled with the initial-exec tls model, which means that it must be an (in)direct dependency of the main executable. It can't be loaded through dlopen. (If it is a dependency of a dlopened dylib, but was already loaded through a dependency of the main executable, that will work just fine however)

Glibc doesn't limit the size of TLS to 2KiB. Rather glibc when doing the initial dynamic linking for the executable which loads all dylib dependencies that don't go through dlopen, glibc will allocate a bit more static TLS space that strictly necessary just in case you want to dlopen a dylib compiled with the initial-exec tls model. If that extra bit of space runs out you get cannot allocate memory in static TLS block. You shouldn't depend on this extra space existing at all though.

How exactly are you trying to load the linter?

1 Like

How exactly are you trying to load the linter?

I'm using libloading, which eventually calls dlopen() with RTLD_LAZY|RTLD_LOCAL.

Is the executable that uses libloading linked against librustc_driver.so itself? If not try doing that. librustc_driver.so can't be loaded using dlopen due to using the initial-exec tls model.

That was something we threw around over here, but I'm not sure how to do it. What's the magical incantation for Cargo.toml?

#![feature(rustc_private)] extern crate rustc_driver; at the top of your main.rs while making sure to compile your executable with the exact same nightly as the plugin you want to dlopen.

Thanks. That did it. I also had to add the directive to the tests file, otherwise cargo test would fail with the same error.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.