Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot allocate memory in static TLS block #27

Closed
mbergkvist opened this issue Apr 8, 2022 · 7 comments · Fixed by #31
Closed

Cannot allocate memory in static TLS block #27

mbergkvist opened this issue Apr 8, 2022 · 7 comments · Fixed by #31

Comments

@mbergkvist
Copy link

mbergkvist commented Apr 8, 2022

Hi! Thanks for a great project, it has helped us a lot when building and deploying to AWS Lambda.

I get a similar error as discussed in #4,
target/release/deps/libthiserror_impl-c21f6147db4ecc92.so: cannot allocate memory in static TLS block

when I'm building with
cargo +nightly zigbuild -p lambda --release --target aarch64-unknown-linux-gnu.2.26

in a Docker container from

ARG RUST_VERSION=1.60
FROM rust:$RUST_VERSION as builder

RUN curl "https://ziglang.org/download/0.9.1/zig-linux-aarch64-0.9.1.tar.xz" | tar -J -x -C /usr/local/bin && \
    cargo install cargo-lambda --version 0.5.3 && \
    cargo install cargo-zigbuild --version 0.8.1

FROM rust:$RUST_VERSION
COPY --from=builder /usr/local/cargo/bin/cargo-lambda \
    /usr/local/cargo/bin/cargo-zigbuild \
    /usr/local/cargo/bin/
COPY --from=builder /usr/local/bin/zig-linux-aarch64-0.9.1 \
    /usr/local/bin/zig-linux-aarch64-0.9.1
RUN rustup default nightly-aarch64-unknown-linux-gnu && \
    ln -s /usr/local/bin/zig-linux-aarch64-0.9.1/zig /usr/local/bin/zig

Building without explicit glibc-version works fine, both on nightly and stable channel.

I'm not sure what the culprit is. Moving the failing code to another package does not reproduce the error, so I guess it's not the code per se. Any ideas what's the cause? Searching the internet indicates it's related to jemalloc?

I'll see if I can recreate the error with some sample code.

@messense
Copy link
Member

messense commented Apr 8, 2022

What's your host machine architecture? #4 only happens when the host triple is the same as the target triple.

And have you tried cargo clean then cargo zigbuild?

@mbergkvist
Copy link
Author

The host where I'm running the Docker container is aarch64-apple-darwin when building locally, and the image when building in CodePipeline is aws/codebuild/amazonlinux2-aarch64-standard:2.0 so I assume that is aarch64-unknown-linux-gnu .

I had to switch to the nightly channel to get the specified glibc-version to be picked up by zig, as mentioned in #4, and that worked fine until I got the cannot allocate memory in static TLS block error.

I'm doing cargo clean between each build when I'm trying to find out what wrong here, just to make sure to not inherit anything from previous builds.

I only get the error when I specify the glibc version.

cargo zigbuild -p lambda --release --target aarch64-unknown-linux-gnu and cargo +nightly zigbuild -p lambda --release --target aarch64-unknown-linux-gnu works fine (does not end in any error), only cargo +nightly zigbuild -p lambda --release --target aarch64-unknown-linux-gnu.2.26 is failing.

@messense
Copy link
Member

messense commented Apr 9, 2022

It would be helpful if you can create a minimal reproducer, thanks!

@mbergkvist
Copy link
Author

I've now shared a stripped down project with you in https://github.com/mbergkvist/allocate-memory-in-static-tls-block.

@messense
Copy link
Member

Thanks for the report and the minimal reproducer, should be fixed in #31 now. It was a oversight from #19 .

@mbergkvist
Copy link
Author

Thanks for the swift help. Much appreciated.

@mbergkvist
Copy link
Author

should be fixed in #31 now

I've verified that release 0.8.3 also fixed the problem we had in our project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants