Linking error and memory leak using Leptos on Linux

help
1

Hello everyone,

I have an issue when compiling a simple Leptos (with Axum) + leptos_i18n project.
I suspect it is linked to recursive calls somewhere because at some point I had to fix the error:

 Compiling server v0.1.0 (/i18n_leptos_mre/server)
error: queries overflow the depth limit!
  |
  = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`server`)
  = note: query depth increased by 130 when computing layout of `{async block@<leptos::into_view::View<tachys::html::element::HtmlElement<tachys::html::element::elements::Main, (tachys::html::class::Class<tachys::view::static_types::Static<"mt-20">>,), ((leptos::into_view::View<tachys::html::element::HtmlElement<tachys::html::element::elements::Header, (tachys::html::class::Class<tachys::view::static_types::Static<"absolute inset-x-0 top-0 z-50 pt-2">>,), ((tachys::html::element::HtmlElement<tachys::html::element::elements::Nav

Once fixed, using 1.84-nightly everything is fine up until adding a div with translations macros to my home page app/src/page/home.rs. (line 104 after the comment)

When the div' is not commented I get this linking error

error: linking with `cc` failed: exit status: 1
|
= note: LC_ALL="C" PATH="/home/arnaud/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/b...

Complete log

So I tried with the system's default linker using:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Zlinker-features=-lld"]

which doesn't crash but uses around 55GB of RAM.

On stable 1.82-stable this small project also uses 50GB of RAM when building. So there seems to be a memory leak because this project has basically 1 simple page.

I know the memory leak is probably caused by code in the leptos or leptos_i18n crate, but while it's a combination of the 2, how can I figure it out?

Is the linking error something that should be posted as an issue in the rust-lang Github ?

Are these 2 problems linked ? I'm out of my depth on this one.

Can anyone replicate the error ? I'm on Ubuntu 24.04 64bit with 32GB of RAM and 128GB of swap space.

Here is the repo https://github.com/arnaudpoullet/leptos-i18n-compile-error
in the root simply run cargo build --package=server --bin=server --no-default-features

2

= note: rust-lld: error: /leptos-i18n-compile-error/target/debug/deps/server-37818cf8471b3ec3.00tnafkygr89nmzbal1k3w313.rcgu.o:(.debug_info+0x9f): relocation R_X86_64_32 out of range: 4353330711 is not in [0, 4294967295]

Why do you have a >4GB object file? It fails because the relocations are 32-bit (the object file uses the x86_64 small code model).

It looks like you can use the large code model with:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Zlinker-features=-lld", "-Ccode-model=large"]

But also, the huge object file is concerning for so many reasons.

edit: The error message also suggests that debug symbols could be the reason for object file bloat. You could try split-debuginfo to put all symbols in a separate file.

3

Hi,

Thank you for your reply! I have no idea why there is such a big object file, I did not put it there. Using the large code model with the -lld, as before, does not fail but uses up to 90GB in RAM.

I tried using the large code model with the rust-lld, just putting:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Ccode-model=large"]

but that results in the same error:

[..]
note: rust-lld: error: /leptos-i18n-compile-error/target/debug/deps/server-37818cf8471b3ec3.7svacpgv4px1l8z8dweh9ffpz.rcgu.o:(.debug_info+0x96): relocation R_X86_64_32 out of range: 4353333384 is not in [0, 4294967295]
          >>> referenced by 7svacpgv4px1l8z8dweh9ffpz; consider recompiling with -fdebug-types-section to reduce size of debug sections
[..]

Using:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-Csplit-debuginfo=unpacked"]

does work! RAM usage is back to normal and no linking issue.
Adding "-Ccode-model=large" does not really change anything.

This also solves the RAM issues with 1.82-stable (there was no linking issue)

So this does allow me to continue working on my project, but still I'm wondering, is this normal ?
Do we now completely ignore the issues I have with a default configuration ?
It's a fairly basic fullstack leptos web-application, for new users this is not the best experience.

Isn't the nightly-only linking issue a bug ?

4

I have not seen this before at all. But I don't use leptos. (I don't even know what it is... Oh, it's web app stuff. No interest.)

Frankly, it's shocking that you could end up with several gigabytes of debug symbols from just a few direct dependencies. The lock file only has around 350 packages total. Nothing about this stands out as "obviously just too much code". I guess it could be caused by super aggressive monomorphization or something.

I also don't know who should take the blame. You would have to inspect the debug symbol files to get a sense of which crate is contributing the most symbols. Regardless of which crate it turns out to be, I recommend reporting this issue to them.

edit: Oh I didn't notice you had called out that this only happens with rustc nightly. In that case, yeah it's probably this compiler bug: Large types cause linker failure · Issue #130729 · rust-lang/rust · GitHub

1 Like