I am newbie in Rust prog. language, although I knew PHP & Javascript. The problem is in this simple beginner code :
fn main() {
let x = 4; // immutable by default,
println!("x = {}", x);
let x = 5; // Redefining x
println!("x = {}", x);
}
According to a youtube tutorial(Tech With Tim) it can be run (showed in his monitor), but when I try to compile and run (cargo run), it can't be run and show this error :
"error: could not execute process target\debug\lat5.exe (never executed)
Caused by:
Access is denied. (os error 5)",
and Avira tell that is a HUER/APC threat....?
Related
How does tokio::runtime::Handle.block_on differ to tokio::runtime::Runtime.block_on? The Handle.block_on causes some code to hang whereas the Runtime.block_on works fine.
This is how I create the Handle. The Runtime is the same minus the last 2 lines.
let runtime = runtime::Builder::new_multi_thread()
.enable_all()
.build()
.unwrap()
.handle() // not needed for Runtime
.clone(); // ---
Then I call a function which with this:
async fn run(){
// calls get data
}
self.runtime.block_on(run())
This is the code where it hangs. When running from the Runtime it works fine, with the Handle it hangs at TcpStream::connect().
async fn get_data(addr: String) -> Result<Data> {
let c = TcpStream::connect(addr.clone()).await?; // hangs here
let t = get_data_from_connect(c).await?;
return Ok(t);
}
I fixed this by making sure that the Runtime object does not go out of scope and get dropped. I was under the impression that only the Handle is needed to keep the runtime alive but only the Runtime object itself can.
In thrussh's documentation they have server and client example code.
Code based on the example server code has been working fine in various projects. However, the client example fails at the line:
let mut channel = session.channel_open_session().await.unwrap();
The error I get is this:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Disconnect', src/main.rs:121:64
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I'm not sure what is causing the panic as everything works fine up until that point. The server calls both finished_auth() and channel_open_confirmation() but never gets to call channel_open_session(). I've been looking through the source but I can't seem to identify what's wrong.
Here's the full code
use thrussh_keys::*;
use thrussh::*;
let ssh_config = thrussh::client::Config::default();
let ssh_config = Arc::new(ssh_config);
let sh = Client {};
let key = thrussh_keys::load_secret_key("server.key", passphrase).unwrap();
let mut agent = thrussh_keys::agent::client::AgentClient::connect_env().await.unwrap();
agent.add_identity(&key, &[]).await.unwrap();
let mut session = thrussh::client::connect(ssh_config, format!("localhost:{}", config.port), sh)
.await
.unwrap();
println!("connected");
if session
.authenticate_future(config.user, key.clone_public_key(), agent)
.await
.1
.unwrap()
{
println!("session authenticated");
let mut channel = session.channel_open_session().await.unwrap();
channel.data(&b"Hello, world!"[..]).await.unwrap();
if let Some(msg) = channel.wait().await {
println!("{:?}", msg)
}
}
the code on the server side is the same as the server example aside from writing the key to disk so that it can be used in the client code.
I guess the channel open response package was consumed by the fn channel_open_confirmation for some reason. Therefore, the wait_channel_confirmation will be pending for receiving the confirmation package for ever.
If you comment out the function implementation channel_open_confirmation for Client, it should work.
The trait does have a default implementation for this method, which sends out the OpenChannelMsg.
So, the demo is improper, unluckily, I have no access to report this issue.
My rust project uses Command to execute a process.
Sometimes (low frequency) when I run this code the call to status.code() returns None. I am usually using Mac OS Catalina Beta 1, rustc 1.36.0 - but it happens in Travis too (will have to go and find logs of OS/rustc there).
I was treating this as an error but "randomly" it would cause local and travis builds to fail, so now I'm ignoring it - but it would be nice to understand what's causing it.
In failure cases, re-running immediately will cause it to succeed.
let output = Command::new(&command)
.args(command_args)
.stdin(Stdio::inherit())
.stdout(Stdio::inherit())
.stderr(Stdio::piped())
.output()
.chain_err(|| "Error while attempting to spawn command to compile and run flow")?;
match output.status.code() {
Some(0) => Ok("Flow ran to completion".to_string()),
Some(code) => {
error!(
"Process STDERR:\n{}",
String::from_utf8_lossy(&output.stderr)
);
bail!("Exited with status code: {}", code)
}
None => Ok("No return code - ignoring".to_string()),
}
My question is not why this could happen (I know that the docs say "terminated by signal") but why it is happening, as no-one AFAIK is sending a signal to it, I seriously doubt any OOM or other such issues.
Read the manual:
On Unix, this will return None if the process was terminated by a signal; std::os::unix provides an extension trait for extracting the signal and other details from the ExitStatus.
use std::os::unix::process::ExitStatusExt;
use std::process::Command;
fn main() {
let mut child = Command::new("sleep")
.args(&["10"])
.spawn()
.expect("failed to spawn child");
child.kill().expect("failed to kill on child");
let status = child.wait().expect("failed to wait on child");
match status.code() {
None => {
println!("{:?}", status.signal());
()
}
_ => (),
}
}
You could use from_c_int() to have a pretty print of the signal type.
I have a Rust program which is exiting silently without any trace of the reason in the logs. This would happen after several successful calls to the same method. The last log I see is one after which a FFI call is made. I do not get a log after the return of the FFI call.
use cpython;
use cpython::ObjectProtocol;
use cpython::PyResult;
fn is_complete(&self, check: bool) -> Result<bool, PyModuleError> {
let gil = cpython::Python::acquire_gil();
let py = gil.python();
debug!("Calling complete"); //This is the last log
let res = self
.py_complete
.call_method(py, "complete", (check,), None)
.expect("No method complete on python module")
.extract::<bool>(py).unwrap();
if res {
debug!("Returning true"); //This does not appear
Ok(true)
}
else {
debug!("Returning false"); //This does not appear
Ok(false)
}
}
The Python module does return a value as I had debug logs there as well to confirm.
I have tried using RUST_BACKTRACE=1 but in vain.
Calling write_all on a file returns an error with the description: os error. Debug printing the error outputs: Err(Error { repr: Os(9) })
What does the error mean?
You didn't include any code, so I had to make wild guesses about what you are doing. Here's one piece of code that reproduces your error:
use std::fs;
use std::io::Write;
fn main() {
let mut f = fs::File::open("/").unwrap();
// f.write_all(b"hello").unwrap();
// Error { repr: Os(9) }
match f.write_all(b"hello") {
Ok(..) => {},
Err(e) => println!("{}", e),
}
// Bad file descriptor (os error 9)
}
If you use the Display ({}) format instead of Debug ({:?}), you will see an error message that is nicer than just the error code. Note that unwrap will use the Debug formatter, so you have to use match in this case.
You could also look up the error code in the kernel source. You don't indicate if you are running Windows (unlikely), OS X or Linux, so I guessed Linux.
There are lots of SO questions that then explain what the code can mean, but I'm sure you know how to search through those, now that you have a handle on the problem.