Closed hgrecco closed 6 years ago
dtolnay
commented
6 years ago Would you be able to share a minimal Dockerfile that reproduces this issue?
Can you bisect to find the oldest serde_derive version that does not work? Are you saying 1.0.33 works and 1.0.34 does not?
hgrecco
commented
6 years ago The following gist contains a configuration that fails to compile in my docker installation (and works if I use 1.0.33).
Notice that it does compile in my local computer. But it does not work in my docker.
I have not tried with 1.0.34. I can only say that it works with 1.0.33 and does not work with 1.0.52, 1.0.62 and 1.0.66. I will try later.
(Again, I do not think this is a serde bug but rather some resource problem in the docker installation, but I am hoping that someone has found the same thing and can explain me why and how to fix it)
dtolnay
commented
6 years ago I tried your Dockerfile on a t2.micro in EC2 with 1 GiB memory and docker version 1.13.1, and it appeared to complete successfully. Are you building not on Linux? SIGKILL could be from the oom killer. I don't know much about Docker but running it on platforms other than Linux may need some setting to make more memory available to the container.
hgrecco
commented
6 years ago I am building on linux, it is ubuntu box. But with only half of the memory. I think it might be the oom killer as you said. Maybe docker stats is not reporting correctly the peak usage.
Docker version 17.09.0-ce, build afdb6d4
Kernel Version: 4.4.0-96-generic
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 488.2MiBI will try to change it. However, I do have a question. A smaller crate with only
serde = "=1.0.62"
serde_derive = "=1.0.62"
serde_json = "=1.0.21"compiles just fine. Why is this important? I thought that each rustcc command was starting and ending and therefore the size of the crate should not matter to compile each dependency.
dtolnay
commented
6 years ago It could be running lots of builds in parallel for the large dependency graph of actix-web. If you add RUN nproc --all in the Dockerfile how many processors does it say there are? Those could be that many different parallel rustc invocations consuming memory.
If nproc reports greater than 1, try invoking cargo with -j1 flag to build only one crate at a time.
I am closing the issue because it seems like this is not something that is going to involve changes to Serde code. Please follow up in https://github.com/rust-lang/cargo if you can't get it working.
hgrecco
commented
6 years ago I appreciate the time you put into this. I will follow your suggestion. Right now I managed to cross compile my binary using rust-musl-builder which works surprisingly well.
(Disclaimer: I am not an expert in docker or in the rust compiler)
This is NOT a bug report. Just a comment with the hope that somebody can give me a tip.
I have a rust web service which was running flawlessly for several months. It is compiled and run inside a docker container. Recently, I added a few features and use the opportunity to upgrade some deps including
serde_deriveto latest. In my computer it compiled and run without any problem. But I was not able to compile it again inside the docker container until I downgradedserde_deriveto1.0.33. I have seen that 1.0.33 is one of the last versions in whichserde_derive_internalswas outsideserde_derive.It seems that within (my) docker container, the compilation of the latest serde_derive is halting (and I get signal: 9, SIGKILL: kill). One possibility is that I am getting a memory error, but
docker statsonly shows 43% of memory usage. Also, I have tried to compile a smaller project with only latestserdeand latestserde_derive, and it works perfectly. This would point again to a memory problem, I guess.The rest of the packages have no problem compiling in their latest version. I tried rust 1.25.0 and 1.26.2. Same results in both