Stuck in compilation on rust-musl

[xrl]

I am building for Linux using Docker for Mac and the rust-musl-builder image. I am using nightly-2019-11-13 and hitting a bug with the k8s-openapi dependency never completing its build. The new bits of my Cargo.toml look like:

k8s-openapi = { version = "0", features=["v1_15"] }
kube = { version = "0.18.1", features=["openapi"]}

I don't expect anyone here to have the answer (probably a rustc bug!) but I wanted to share. Just in case others have hit the issue and have some tips or perhaps a way to get rustc to dump what it's working on so I can file a ticket with rust-lang.

[Arnavion]

With Docker for Mac, I believe the container runs inside a VM that Docker creates for you. Try tweaking the parameters of that VM to give it more RAM. 5 GiB or so should be sufficient.

[xrl]

Great point. I have been running an aggressive configuration like this:

and top inside the container shows only 20% or so of the RAM in use and 1 CPU pegged at 100% for 15+ minutes. Sounds like an infinite loop somewhere.

[xrl]

Not sure if it helps, but I'm trying to checkout different k8s-openapi releases to see which ones will build, I had to go back:

rust@c4605e17a2e8:~/src/k8s-openapi$ git checkout v0.5.1
rust@c4605e17a2e8:~/src/k8s-openapi$ cargo build --features=v1_15
   Compiling k8s-openapi v0.5.1 (/home/rust/src/k8s-openapi)
    Building [======================================================>  ] 42/43: k8s-openapi
[[ stuck ]]
rust@c4605e17a2e8:~/src/k8s-openapi$ git checkout v0.4.0
rust@c4605e17a2e8:~/src/k8s-openapi$ cargo build
[[ worked ]]

all other newer releases would block indefinitely.

[Arnavion]

and 1 CPU pegged at 100% for 15+ minutes. Sounds like an infinite loop somewhere.

It maxing one core is not completely unexpected. Most of rustc is single-threaded and it spends a lot of time in that state for k8s-openapi.

Not finishing in 15 minutes is abnormal though.

---

rust@c4605e17a2e8:~/src/k8s-openapi$ git checkout v0.4.0
rust@c4605e17a2e8:~/src/k8s-openapi$ cargo build
[[ worked ]]

Just to be sure, I assume you passed --features v1_13 here?

The issue may possibly be not of 0.4.0 vs 0.5.0 but of v1_13 vs 1_15. See https://github.com/clux/kube-rs/issues/62#issuecomment-523681030 . As I said there, 0.5.0 has fewer types than 0.4.0 so it should be easier to compile, but the difference in that issue was that v1_15 had a few more types than v1_13 and was just enough to push the machine over its RAM limit.

Since you gave your VM 6 GiB, that shouldn't be the reason, but it's still worth checking if 0.6.0 with v1_13 works for you.

---

Are you saying you only see this with the musl docker image and not on your host directly?

---

I'm building the image locally too, to rule out the specific toolchain being the problem.

[Arnavion]

I'm building the image locally too, to rule out the specific toolchain being the problem.

Built the image with:

$ docker build --build-arg TOOLCHAIN=nightly-2019-11-03 -t ekidd/rust-musl-builder .

It works for me. rustc maxes out at about 750% CPU and ~4.7 GiB RSS, then succeeds.

$ docker run -it --rm ekidd/rust-musl-builder rustc -vV

rustc 1.40.0-nightly (91fd6283e 2019-11-02)
binary: rustc
commit-hash: 91fd6283e658e2c7aab2d3f5206fc1891f486af2
commit-date: 2019-11-02
host: x86_64-unknown-linux-gnu
release: 1.40.0-nightly
LLVM version: 9.0

$ docker run -it --rm -v "$(realpath ~/.cargo/git):/home/rust/.cargo/git" -v "$(realpath ~/.cargo/registry):/home/rust/.cargo/registry" -v "$PWD:/home/rust/src" -e RUST_BACKTRACE=full -e CARGO_INCREMENTAL=0 ekidd/rust-musl-builder cargo build --features 'v1_16'

   Compiling k8s-openapi v0.6.0 (/home/rust/src)
    Finished dev [unoptimized + debuginfo] target(s) in 1m 02s

$ docker run -it --rm -v "$(realpath ~/.cargo/git):/home/rust/.cargo/git" -v "$(realpath ~/.cargo/registry):/home/rust/.cargo/registry" -v "$PWD:/home/rust/src" -e RUST_BACKTRACE=full -e CARGO_INCREMENTAL=0 ekidd/rust-musl-builder cargo build --features 'v1_15'

...

   Compiling k8s-openapi v0.6.0 (/home/rust/src)
    Finished dev [unoptimized + debuginfo] target(s) in 1m 03s

Of course this is with the container running on the (Linux) host directly, not inside any VM.

[Arnavion]

@xrl Can you try master with https://github.com/Arnavion/k8s-openapi/commit/7d80ac1f08cb88158e5d9db2afecfbe8c2eea30d or newer? It approximately halves the RSS usage, to ~3 GiB.

[xrl]

I'm a jerk and I forgot to follow up. Things are going fine, I think it has more to do with some aggressive heat-related downclocking on my Intel-powered Macbook Pro. Your patches DID help but I have not gathered good numbers (a lot of variables have changed in the intervening weeks).

[xrl]

Let's close this issue. Thanks!