Every time I try to cargo build rbspy it hangs

help
1 
% git clone https://github.com/rbspy/rbspy.git    

% cargo version                                                  
cargo 0.25.0-beta (64326d735 2018-01-14)

% cd rbspy
% RUST_LOG=cargo::core::resolve,cargo::core::registry cargo build

...
lp", "consoleapi", "winbase", "processthreadsapi", "sysinfoapi", "processenv"}
  failure_derive v0.1.1: {"default", "std"}
  byteorder v1.2.1: {"std", "default"}
}
TRACE:cargo::core::registry: getting packages; sources=5

(STUCK)

strace: Process 29063 attached
restart_syscall(<... resuming interrupted poll ...>

Any ideas why this is getting stuck and how I would go about debugging it?

Also hangs in stable, I tried beta just in case.

1 Like
2

Hi Sam,

(Nice to see a Discourse Eminence among us! :heart: )

I have no experience with Ruby nor RubySpy, but I had a rust-instance lying around anyway, so I quickly tried to reproduce. It worked for me :expressionless: ?

I do notice that you are using a cargo beta, is that required? nevermind, you wrote that you also have the problem on stable...

Also, the point where you wrote "STUCK" is where my first attempt (on outdated rustc that couldn't compile bitflags) started downloading the missing dependencies.
Maybe network connectivity problems, proxies, something like that?

% cargo --version
cargo 0.24.0 (45043115c 2017-12-05)
% rustup --version
rustup 1.10.0 (c6a8f7c60 2018-01-25)
% rustc --version
rustc 1.23.0 (766bd11c8 2018-01-01)

% RUST_LOG=cargo::core::resolve,cargo::core::registry cargo build
...
TRACE:cargo::core::resolver: resolved: graph: Graph {
	<SNIP>
}

features: {
	<SNIP>
}
TRACE:cargo::core::registry: getting packages; sources=5
   Compiling utf8-ranges v0.1.3
   ....
   Compiling env_logger v0.3.5
   Compiling rbspy v0.1.1 (file://workspace/rbspy)
    Finished dev [unoptimized + debuginfo] target(s) in 49.90 secs
3 Likes
3

Thanks heaps Jules,

I also suspect this is somehow network related. With RUST_LOG=debug I am getting:

DEBUG:cargo::core::resolver: checking if winapi v0.2.8 is already activated
DEBUG:cargo::core::resolver: checking if void v1.0.2 is already activated
DEBUG:cargo::core::resolver: checking if kernel32-sys v0.2.2 is already activated
DEBUG:cargo::core::registry: load/match    registry `https://github.com/rust-lang/crates.io-index`
DEBUG:cargo::core::registry: load/match    registry `https://github.com/rust-lang/crates.io-index`
DEBUG:cargo::core::resolver: checking if syn v0.11.11 is already activated
DEBUG:cargo::core::resolver: checking if quote v0.3.15 is already activated
[STUCK]

I wonder if this is somehow ipv6 related, is there a way to teach cargo only use ipv4 temporarily?

4

(We seem to be in very impractical timezones for interactive help :neutral_face: , have you visited the IRC yet? That should have some shorter ping times :wink: )

I'm not aware of any ipv4 flags or anything. I also didn't find any "ipv4", "ip4" or "ip v4" references, not even when ripgrep-ing the source code.. (though they may still exist, I'm not that much of a cargo guru, and may suck at searching the codebase..)

I do know about the --frozen flag, which forbids any network activity, but does expect the registry and downloaded packages to be up to date. This could maybe be (ab)used to debug further:

From the cargo docs:

As of Rust 1.11.0 Cargo understands a new flag, --frozen, which is an assertion that it shouldn't touch the network. When passed, Cargo will immediately return an error if it would otherwise attempt a network request. The error should include contextual information about why the network request is being made in the first place to help debug as well. Note that this flag does not change the behavior of Cargo, it simply asserts that Cargo shouldn't touch the network as a previous command has been run to ensure that network activity shouldn't be necessary.

(emphasis mine).
It may be a nice hack to see at which point cargo hangs, because the "would have used network" error will tell you what it is trying to do.
If this coincides with your "STUCK" point, that might be a good indication :slight_smile:

Also, in general, people seem to sometimes have success fixing strange issues if they wipe (or temporarily move) their ~/.cargo/registry. (e.g. here)

5

interesting... very weird thing, sudo cargo build works fine cargo build does not. --frozen did not help, nor did nuking ~/.cargo

1 Like
6

Looks like this is nothing to do with cargo directly, just running rustc on my box hangs:

futex(0x7f8a97aa180c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f8a97aa1818, FUTEX_WAKE_PRIVATE, 2147483647) = 0
rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f8a9def34b0}, {SIG_DFL, [], 0}, 8) = 0
open("/proc/self/maps", O_RDONLY|O_CLOEXEC) = 3
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "55beef2d1000-55beef2d3000 r-xp 0"..., 1024) = 1024
read(3, "          /usr/local/lib/libaren"..., 1024) = 1024
read(3, "94a1c000-7f8a94a1d000 r--p 00043"..., 1024) = 1024
read(3, "0d7dc60162.so\n7f8a97a3a000-7f8a9"..., 1024) = 1024
read(3, "/lib/x86_64-linux-gnu/librt-2.23"..., 1024) = 1024
read(3, ".so\n7f8a98331000-7f8a98530000 --"..., 1024) = 1024
read(3, "01 2364537                    /u"..., 1024) = 1024
read(3, "                 /usr/local/lib/"..., 1024) = 1024
read(3, "1ec8.so\n7f8a996af000-7f8a996b100"..., 1024) = 1024
read(3, "-p 00051000 08:01 2364547       "..., 1024) = 1024
read(3, "8ae8f9c9152b9183.so\n7f8a9ac62000"..., 1024) = 1024
read(3, ".so\n7f8a9b10f000-7f8a9b110000 rw"..., 1024) = 1024
read(3, "000-7f8a9b5a1000 rw-p 0001e000 0"..., 1024) = 1024
read(3, "                   /usr/local/li"..., 1024) = 1024
read(3, "brustc_metadata-1b4e3bb15c9d6681"..., 1024) = 1024
read(3, "5b79e143c2b1.so\n7f8a9c9d0000-7f8"..., 1024) = 1024
read(3, "7f8a9d3d1000-7f8a9d3d2000 rw-p 0"..., 1024) = 1024
read(3, "l/lib/librustc_save_analysis-5af"..., 1024) = 1024
read(3, "8a9debe000 rw-p 00000000 00:00 0"..., 1024) = 1024
read(3, "7f8a9e5db000-7f8a9e840000 r-xp 0"..., 1024) = 1024
read(3, "8a9eca7000 r-xp 00000000 08:01 1"..., 1024) = 775
close(3)                                = 0
sched_getaffinity(24497, 32, [f, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]) = 32
rt_sigaction(SIGSEGV, {0x7f8a9e30e8e0, [], SA_RESTORER|SA_STACK|SA_SIGINFO, 0x7f8a9def34b0}, NULL, 8) = 0
rt_sigaction(SIGBUS, {0x7f8a9e30e8e0, [], SA_RESTORER|SA_STACK|SA_SIGINFO, 0x7f8a9def34b0}, NULL, 8) = 0
sigaltstack(NULL, {ss_sp=NULL, ss_flags=SS_DISABLE, ss_size=0}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8a9eea1000
sigaltstack({ss_sp=0x7f8a9eea1000, ss_flags=0, ss_size=8192}, NULL) = 0
futex(0x7f8a93800a40, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
futex(0x7f8a93800a40, FUTEX_WAIT_PRIVATE, 2, NULL

[STUCK]
2 Likes
7

Ok, wow! That is weird.
I also haven't heard of rustc hanging before..

I'm afraid that you've debugged this way beyond my ability to help, with all the strace and all.. I'm also not sure who to ping on stuff like this.. random internals forum members maybe...

Just a random thought:
If sudo seems to help, that really implies some permission limit somewhere.. have you tried completely wiping your rustc installation, and reinstalling with rustup?

Sorry to not be more helpful! :slightly_frowning_face:

8

The fact that it builds fine with sudo and fails without implies that there is a permissions issue on one of the files/directories that rust is trying to write to. The file/directory is probably owned by root from running with sudo previously. I would try running something like the following:

find ~ -uid 0 -ls

Any files listed are owned by root and probably shouldn't be. If you want to change ownership of all of the found files then you could do:

sudo find ~ -uid 0 -exec chown $(id -un) {} \;
1 Like