Failed to mmap #2808
Comments
|
Whoa, haven't seen that one before! Are you perhaps running on a system that's running low on memory? It may be worth running |
There is also one thing I forgot to mention and it may be the cause. That Ubuntu is inside VirtualBox 5.0.22 on Windows host. I'm using this setup for years and never had any problems, so I haven't thought about mentioning this in first place. Definitely RAM usage isn't an issue (host or guest). This may be related to #1578. My whole home dir is on vbox shared folder. I'm not sure whether it's important, but i'm using git from guest without any issues. libgit2/git2go#194 (comment) looks familiar. |
|
Interesting! Could you gist the full syscall log as well? It looks like it's attempting to map whatever file descriptor 5 is, and it may be good to see how that's in play |
|
https://paste.ubuntu.com/17997204/ I guess it's |
|
cc @carlosmn, does this sound familiar in libgit2? It looks like the relevant syscalls leading up to the failure here are: I think that cargo is using libgit2 0.2.23 right now FWIW |
|
It looks to be the same issue as the one in the git2go tracker. The VirtualBox filesystem does not like something we're doing, but it's not clear what. It's possible that it doesn't support files with holes even though it doesn't actually complain about them, or maybe it's just with mmap. Someone reported the tests run fine, which is really odd as it's the same code. It probably doesn't help that it seems to be translating unix calls into Windows filesystem calls, which breaks the assumptions we're making in the library. @miedzinski can you clone fine if you're on VBox but without a shared home dir? |
|
@carlosmn I can use all git commands (including clone) on vboxsf. If you are asking about libgit2 (which git binary doesn't use, right?), then you have to wait few hours until I come back home and try it with cargo. |
|
@carlosmn, @alexcrichton, it works flawlessly. This is the same virtual machine, but this time cargo directory is on ext4. |
|
@miedzinski could you try compiling this and see if it runs into the same error when cloning onto a shared directory? #include <git2.h>
#include <assert.h>
int main() {
git_repository *repo;
assert(git_libgit2_init() == 1);
assert(git_clone(&repo,
"https://github.com/rust-lang/crates.io-index",
"crates.io-index",
NULL) == 0);
} |
|
Built against 0.24.1-2 from Ubuntu repository. |
|
@miedzinski could you try using |
|
Hm it's not clear from that gist that it's the same mmap error you're hitting with Cargo. It's also doing a different operation with a clone rather than a fetch, so that may be factoring in as well. It may be worth poking around various incantations to see if it can be reproduced with just libgit2 so we can report the bug upstream. |
|
That error looks like libgit2 was not built with HTTPS support. Trying with I've opened libgit2/libgit2#3845 to track this upstream, but I'm not sure that there's a fix that doesn't involve a lot of yak shaving so we don't need to read the data back from disk. |
|
Sounds good to me, thanks @carlosmn! |
|
@carlosmn, there is definitely something wrong here. I have changed this code to: and assertion was failing as well. I have tried different URLs (like @alexcrichton, is it possible to change cargo directory location? It seems like a good workaround. If not, I can always mount ext4 filesystem on ~/.cargo/. edit: symlink is sufficient. :) |
That's not going to work, since you're aksing for "Operation not permitted" is another error that seems to come from weird interactions between vboxfs and Windows. I'm not sure where the error comes from in that case. |
|
It seems you are right. I have found which URL produced these files. Unlike https version, this creates But assertion still fails. This time strace shows that strace ouput: https://paste.ubuntu.com/18115479/ |
|
Oh that looks like it's a reproduction, from the strace logs: |
|
Well, there is problem with chmods on vboxsf, because Windows doesn't support them. Using Which means all files have chmod 700 inside my $HOME directory. |
|
With Rust 1.11 & cargo 1.12, I get what appears to be a related error: |
|
I have same issue with cargo 1.16 and rust 1.15. The only difference that I'm using KVM+QEMU virtual machine, but with shared home folder as well. My host machine is on Debian, as well as guest. |
|
I think I have hit the same issue on OSX while wanting to be clever and reuse cargo registry between builds on a docker: docker run \
-v $(pwd)/build/.cargo:/root/.cargo \
-v $(pwd):/source jimmycuadra/rust:1.15.0 \
/bin/bash -c "cargo build --release" |
|
This issue is mostly related to vboxsf filesystem. Consider running cargo with strace (look at @alexcrichton comments above) and report to libgit2/libgit2#3845 if it fails the same way on overlayfs (or whatever docker is using right now) or create new issue. |
|
@Nercury Did you come up with a clever way of re-using registry without triggering this bug? |
|
@jml Sorry, no. My project is very small so this is minor for me. |
|
Following the threads further, @jml's solution was to use a partial cache of the relevant pieces:
|
|
@shepmaster I'm not getting any speed improvements using it. The cache folder is also empty. Mind that I only have one dependency which is "Rand" so I wonder if the cache is used for other stuff? |
|
Sorry haven't had a chance to look into this in a while and don't expect to any time soon. I've lost all mental context. |
|
It sounds like there are either workarounds or upstream issues for this, so I'm going to close. Please reopen if I'm incorrect and there's something cargo should be doing here! |
|
Just have met the same bug in WSL ubuntu-20. A hint for who has the same issue: Using local docker volume to map The |
Some strange issue make so that this arch fails to build on Alpine. To not hinder the 3.0.0 release we drop this arch, and hopefully we can reintroduce it in the future. More info here: pyca/cryptography#6673 and here: rust-lang/cargo#2808
|
Out of Memory error when building orjson wheel for armv7 Docker on Ubuntu64. |
|
You should try the workaround I used on my docker image for armv6/armv7 ENV CARGO_NET_GIT_FETCH_WITH_CLI=truePlease let us know if works for you |
|
Hi @williamdes thank you. Yes this works )) |
|
I'd say MAP_SHARED instead of MAP_PRIVATE is a possible if not likely culprit, here. |
I can't install anything with cargo.
or by putting dependency in
Cargo.tomlI am running up-to-date Ubuntu 16.04 LTS.
The text was updated successfully, but these errors were encountered: