[Resolved] Cargo sometimes creates binaries outside of target/ or even outside of the project!?!?


#1

I am getting really spooky, weird behavior from cargo run --bin mybinary. The spooky part is that I can’t reproduce the behavior intentionally!

The weird part is that every once in awhile cargo run --bin mybinary creates a copy of mybinary in the root of the crate, or in an entirely different crate that is is the same directory as the current crate.

I’m running Rust 1.15.1 on macOS Sierra 10.12.3.

My projects basically looked like this (omitting the target directory):

.
├── multibin
│   ├── Cargo.toml
│   └── src
│       ├── bin
│       │   ├── command_one.rs
│       │   └── command_two.rs
│       └── lib.rs
└── singlebin
    ├── Cargo.toml
    └── src
        └── main.rs

So in one terminal inside the multibin directory I run:

multibin $ cargo run --bin command_one
multibin $ cargo run --bin command_two

And in a different terminal inside the singlebin directory I run:

singlebin $ cargo run

And then all of a sudden I notice this strange situation:

.
├── multibin
│   ├── Cargo.toml
│   ├── command_one  <-- Extra copy of binary outside target!
│   ├── command_two  <-- Another one!?
│   ├── main         <-- WEIRDER -- this is the singlebin binary, named main and in the WRONG CRATE!?
│   └── src
│       ├── bin
│       │   ├── command_one.rs
│       │   └── command_two.rs
│       └── lib.rs
└── singlebin
    ├── Cargo.toml
    └── src
        └── main.rs

So I delete the spooky extra binaries, and subsequent runs don’t make them any more. I try to make completely new projects to duplicate the situation, but I can’t make it happen again. So I write it off as a fluke.

But as I keep making more binaries source files in multibin/src/bin, every once in awhile binaries will start showing up in the root of the crate again. But I can’t pin down a pattern as to when it happens so that I can reproduce it.

Ideas?


#2

Hm. Suffice it to say I’ve never run into this!

In the other thread you mentioned you were working on porting shell commands, and I imagine you’re using the local filesystem to test them. No doubt you’ve probably already considered this, but could it be related?


#3

The code in the three commands I have implemented so far are true, false, and yes. It doesn’t get more simple than this. I don’t know if the simplicity of the code is triggering the anomalous behavior or not.

// true
fn main() {
}
// false
fn main() {
    std::process::exit(1);
}
// yes
use std::env;

fn main() {
    let string_to_print = match env::args().nth(1) {
        Some(x) => x,
        None => String::from("y"),
    };
    loop {
        println!("{}", string_to_print);
    }
}

I’m working on sleep now, which actually has a little bit of code in it.


#4

What does your dev environment look like? Editor, plugins, etc. Are you periodically doing profiling/tests/anything special like that, and how so?


#5

Ah! I bet that’s it. I’m using MacVim with Syntastic, rust.vim, and racer. I bet one of them (or a combination of them) is producing the binaries.

I had the source files from both projects open in MacVim, so that makes sense about the cross-pollination of the binary as well.

Yay! Sanity! Dunno how to find which one is doing it or how to fix it, but at least I know what to blame.