Release build runs, debug build fails

Hi all,
I have a reduced version of a program here, that builds fine.
However, when I try to run it, using cargo run or building and then executing from the command line, the debug build comes back with

error: could not execute process `target\debug\p16_fake_search_select.exe` (never executed)

Caused by:
  Access is denied. (os error 5)

or a variant of that (this example is from cargo run) . Furthermore, at the moment of calling the exe, it is removed (!) from the file system.
A release build works as expected.
The same .exe files on another PC have the same behaviour. BTW: I am on W10 machines.
And it all runs fine in the Playground.

This is the code. If you comment in the line //let period = 100; both debug and release builds run fine.

use rand::prelude::*;

// These crates need dependencies in Cargol.toml
use tokio::sync::mpsc;   // oneshot; // , mpsc, oneshot};
use tokio::time::{sleep, Duration};

type Rslt = String;

#[tokio::main]
async fn main() {
    let results = google("golang").await;
    println!("Results: {:?}", results);
}

// Two other versions of this fake searcher have been deleted for isolating the bug 
async fn video(query: String) -> Rslt {
    let period = thread_rng().gen_range(0..=100);
    //let period = 100;
    sleep(Duration::from_millis(period)).await;
    format!("{} result for {}", "Video", query)
}

async fn google(query: &str) -> Vec<Rslt> {

    let query = query.to_string();
    let (tx0, mut rx) = mpsc::channel::<String>(1);
    // Spawning 2 other similar processes has been deleted for isolating the bug
    tokio::spawn(async move { tx0.send(video(query).await).await.unwrap(); });

    let mut result = Vec::new();
    // The original tokio::select! has been deleted for isolating the bug
    while let Some(msg) = rx.recv().await { 
            result.push(msg);
    }
    result
}

Anyone have a clue what's going on here?

I would check my AV logs if that happened to me

1 Like

Do you have another instance of cargo run running in the background? If the p16_fake_search_select.exe executable is being used, rustc won't be able to save the new executable and your build will fail.

period remains a range. If you sample an integer from this range it may work:

let mut rng = thread_rng().gen_range(0..=100);
let period = rng.gen();

No, gen_range produces one value within the given range.
(But this point shouldn't matter for issues between debug and release.)

AV logs?

The problem is not in the building: the executable is produced when building.
The problem is in the running: the executable is consumed the moment you run it, either immediately with cargo run or delayed when activating it through a command prompt.

Antivirus program. Looks like it treats your release build as suspicious and deletes it before Cargo starts it.

1 Like

I could not find anything in the AV logs.
Anyway: I do not know what happened, but today I can run all variants of the program (full, reduced, with any of the two lines commented in or out) without problems.
I guess it has not to do with rustc, but with something else on my system (which is partly under group administator control).
Thank you all for thinking along.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.