Skip to content

tokio runtime could not be created #4220

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

Closed
Algorab opened this issue Nov 9, 2021 · 7 comments
Closed

tokio runtime could not be created #4220

Algorab opened this issue Nov 9, 2021 · 7 comments
Labels
A-tokio Area: The main tokio crate C-bug Category: This is a bug. M-runtime Module: tokio/runtime S-waiting-on-author Status: awaiting some action (such as code changes) from the PR or issue author.

Comments

@Algorab
Copy link

Algorab commented Nov 9, 2021

I have a project where I use arm actix(tokio) musl mimalloc. When I run it on the raspberry I can see a error message in the title with running under valgrind.
I am not sure what cause the real problem.
A arm-musl-mimalloc-actix repo is available for reproduce the error and
everything is explained in more detail.

I start rust programming a view month ago, so my experience isn't very deep. Hope somebody can help me or point me to the right direction.

@Algorab Algorab added A-tokio Area: The main tokio crate C-bug Category: This is a bug. labels Nov 9, 2021
@sfackler
Copy link
Contributor

sfackler commented Nov 9, 2021

The error message from valgrind says you should report the bug to them.

@Algorab
Copy link
Author

Algorab commented Nov 9, 2021

It is also crashing when I don't use valgrind, see the core dump. So valgrind isn't the real cause.

@Darksonn Darksonn added the M-runtime Module: tokio/runtime label Nov 9, 2021
@Darksonn
Copy link
Contributor

Darksonn commented Nov 9, 2021

It says that it failed with Os { code: 38, kind: Unsupported, message: "Function not implemented" }. Would you be able to a blank project that just creates a new Runtime, one test with enable_io and another test with enable_time?

@taiki-e
Copy link
Member

taiki-e commented Nov 9, 2021

messense/rust-musl-cross uses musl 1.2, but libc uses musl 1.1. EDIT: Nah, they use musl 1.1 for 32-bit targets, but in any case, -crt-static seems to work.
Try building with RUSTFLAGS='-C target-feature=-crt-static'.

(I have tested it locally using another cross-testing tool, it seems to work fine with -crt-static.)
related: sfackler/rust-openssl#1462

@taiki-e taiki-e added the S-waiting-on-author Status: awaiting some action (such as code changes) from the PR or issue author. label Nov 9, 2021
@Algorab
Copy link
Author

Algorab commented Nov 10, 2021

@taiki-e I tried this flag. This produces a dynamic linked library with this flag, for some reason I want a static one. The raspberry pi 4 can also run in 64bit mode as aarch64. I compiled my program for this target and run the raspberry pi in 64bit and the start behaviour was the same. So I think 32bit cause not the problem.

@Darksonn I create a new repo which hopefully met what you wrote. And did also some tests, the results you can find in the Readme.

@Darksonn
Copy link
Contributor

Since it fails only with mimalloc, it sounds like there is some operation that the runtime needs that is not supported when using mimalloc.

@Algorab
Copy link
Author

Algorab commented Nov 11, 2021

@taiki-e You are right, rust-musl-cross uses the latest version of
musl-cross-make which is version 0.9.9. musl-cross-make 0.9.9 has the latest version of musl 1.1.24. I build a local image with musl 1.2.2 and run the tests on the raspberry. No crashes anymore.

@Darksonn @taiki-e Thanks for helping / pointing me to the right direction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-bug Category: This is a bug. M-runtime Module: tokio/runtime S-waiting-on-author Status: awaiting some action (such as code changes) from the PR or issue author.
Projects
None yet
Development

No branches or pull requests

4 participants